Context

The DbDirectClient re-use the same operation context as the caller operation. 

As a consequence the sub-operation will hold the same locks or re-use the same open snapshot.

The criticality of this architecture is that the sub-operation can abandon the snapshot or free the locks, basically breaking the consistency of the caller operation. 

When called while holding shard role API acquisition, the dbDirectClient will

• detach the transaction resources

• BUT it won't abandon the snapshot, nor release the locks 

Since the resources are detached, locks can't really be accessed. However, the snapshot can still be abandoned.

This has consequence on the consistent snapshot of the parent operation. 

Locked-Acquisitions
For locked acquisitions, abandoning the snapshot is not a big problem because the lock will guarantee the consistency of the snapshot as:

• migration are not allowed (so the sharding filter/descriptions don't update)
• ddls are not allowed (so the catalog doesn't update)

However, an abandoned snapshot won't allow any storage access. The parent operation would still be responsible for re-acquiring the snapshot. This is a confusing/bad user experience.

Lock-Free acquisiiton
The real problem is for lock-free acquisitions. Abandoning the snapshot will effectively break the stability. This is a situation that should be banned. 

Pre work

The following patch invariants every time a dbDirectClient is executed with

• a snapshot open
• acquisition in scope 

Note that this overlaps both lock free and locked acquisition, so not every case is an actual issue.

Goal
The goal is to ban having lock-free acquisition in scope when entering the dbDirectClient.

This should be a first part of a series of ticket where we should ban every acquisition from being scoped when executing the dbDirectClient 

I expect this ticket to take at least 2 iterations, as banning the acquisition will need to re-think on how to re implement an equivalent logic.