Invocations waiting for a new topology should resume in parallel

When a command requires a topology newer than the current topology, it uses StateTransferLock.transactionDataFuture() to wait for the newer topology. When the tx data is received for the newer topology, some (most?) of the waiting operations do not use a separate executor, instead they are all resumed on the thread that received the tx data. If some operations block (e.g. because of a store), it could take a very long time to finish all the blocked operations.