Today, the MultiStatementTransactionRequestsSender (which relies on AsyncRequestsSender) implicitly assumes that it will successfully send commitTxn to all relevant shards. However, in case of an error, it is possible that the requests sender will be destructed before it has had a chance to send out all commands. If this happens, then some transactions may be left dangling on shards, which will block other operations from obtaining locks. To avoid this deadlock, we should wait for all responses before processing results and potentially destructing the object.

Separating this from SERVER-116009 to handle the transactions-specific bug. SERVER-116009 will focus more on defining expectations around the AsyncRequestsSender, but we should implement this fix first to prevent customer issues.

Acceptance criteria: Avoid situation where there could be a dangling transaction on a shard due to destructing AsyncRequestsSender