/**
* Client-side view of a free-standing transaction.
*
+ * <p>
* This interface is used by the world outside of the actor system and in the actor system it is manifested via
* its client actor. That requires some state transfer with {@link DistributedDataStoreClientBehavior}. In order to
* reduce request latency, all messages are carbon-copied (and enqueued first) to the client actor.
*
+ * <p>
* It is internally composed of multiple {@link RemoteProxyTransaction}s, each responsible for a component shard.
*
+ * <p>
* Implementation is quite a bit complex, and involves cooperation with {@link AbstractClientHistory} for tracking
* gaps in transaction identifiers seen by backends.
*
+ * <p>
* These gaps need to be accounted for in the transaction setup message sent to a particular backend, so it can verify
* that the requested transaction is in-sequence. This is critical in ensuring that transactions (which are independent
* entities from message queueing perspective) do not get reodered -- thus allowing multiple in-flight transactions.
*
+ * <p>
* Alternative would be to force visibility by sending an abort request to all potential backends, but that would mean
* that even empty transactions increase load on all shards -- which would be a scalability issue.
*
+ * <p>
* Yet another alternative would be to introduce inter-transaction dependencies to the queueing layer in client actor,
* but that would require additional indirection and complexity.
*