Improve support for parallel processing

Summary
This is a general roadmap to improve support for parallel processing in acquisition modules. It will span several releases, and work needs to be split to make progress possible.
Some of the issues to resolve are described in a wiki.

Already done

• MODFISTO-293 - Error All expected transactions already processed
• MODORDERS-662 - Piece implementation not waiting for futures
• MODORDERS-694 - PendingToOpenEncumbranceStrategy is not thread-safe
• MODFISTO-303 - Backend finance optimistic locking (with the goal of generating errors as opposed to silent data loss)
• Lock budgets to update totals - this resolves budget issues when updating separate orders in parallel
  MODFISTO-304
• Finance optimistic locking UI, to report a 409 error in a clear way
  UIF-379

To do

• POC of a minimal fix of the transaction API; this will resolve issues when updating transactions in parallel for the same order or invoice
  UXPROD-3434, MODFISTO-314
• Apply the POC
  UXPROD-3434, MODFISTO-260, MODFISTO-266, MODFISTO-268, MODFIN-214, MODORDERS-581, MODINVOICE-307
• Check that releasing transactions is not resulting in wrong budgets anymore (the previous fixes are likely to fix that)
  MODFISTO-259
• Simplify the transaction API (one endpoint for transaction summaries)
  MODFISTO-315
• Simplify + optimize usage of finance API in other modules (for instance redo MODINVOICE-360)
• Test performance impact of using more calls in parallel instead of sequentially. If little impact or improvement, revert some module changes, from sequential to parallel processing (to improve readability).
• Optimistic locking in other modules
  UXPROD-3058
• Support PATCH method with transaction summaries
• Update calls to use the new transactions PATCH method, to change order status, set invoiceCancelled, unrelease encumbrances etc.
• Use po line PATCH method to change payment status.
• Look for other PUT calls to replace by PATCH or new endpoints.
• UI-controlled pessimistic locking
  UXPROD-3700

To investigate

• An alternative to the transaction summaries would be to send all the transaction operations at the same time (method+data). This would be a larger change than the ones planned above, but it would simplify implementation further.
• Implementing rollbacks and using the Saga pattern to deal with complex multi-step, multi-app operations, with Kafka. See for instance Saga Pattern in Microservices and Distributed Transactions in Microservices with Kafka Streams and Spring Boot.