Move operation limiter down to TransactionContextWrapper
The limiter tracks the number of operations invoked on the shard leader,
which does not correspond to the number of operations executed on the
frontend.
The appropriate entity to decide what is throttled how is the
TransactionContext, which unfortunately may not exist. We will solve
this problem by making TransactionContextWrapper perform pessimistic
limiting as long as the context does not exist. Once the context is
materialized, the outstanding operation queue is handed off to it and
the context becomes the entity managing the limits.
This patch has the side-effect that committing a transaction requires
number of permits equal to the number of shards it touches. It also
ensures that readAll() is properly throttled.
Change-Id: If91816d806bbb3895592e1f42b0b8e389443d0f7
Signed-off-by: Robert Varga <rovarga@cisco.com>
(cherry picked from commit
9e7a9b3725ad25f9adf85f0ad796b7cf748795a4)