geo: Ability for TS to select a different txn status table based on local vs global requirements

[bmatican]

Context: #9980, #10157

Currently we only support one txn table. When we need to start a txn, we first need to pick a txn status tablet to execute it against. There is code on the TS side to do just that, optimizing for picking a tablet which has a leader on the respective TS.

Once we support multiple status tablets, each with their own placement rules, we will need to improve this picking logic, to select a tablet from either the global table (essentially what we do now) vs a local table. We can still keep the logic of picking a leader, of those!

Couple of other notes

• Eventually, PG will have to flow down info in some PB / RPC, that it wants a global vs local txn tablet. Until that part comes, we can just use a simple gflag though, so we can test the behavior in advance!
• For the global path, for simplicity, we can assume the existing system.transactions table is the global one.
• For the local path, we need to figure out what is the actual placement of the tablet we need. We have not yet clarified what the contract should be, between PG and the TS. For simplicity, I would say we can start with the following assumption: if we need a local txn started at TS1, let's assume the placement information of TS1 is the one we match by (ie: the local TS gflags placement_cloud / placement_region / placement_zone). Then we need to match those against the placement of the various txn tablets available on this TS.
• What is the placement of a particular tablet is known at the master, but we do not flow this to the TS yet. TBD if or how we want to do that. For simplicity though, I think we can get a prototype of this working, by just leveraging the information available in the consensus-meta (ie: check the raft config of the tablet and the placement info of all 3 peers).
• There's also some code where we cache the txn tablets, as we currently expect them to be a fixed set. Would need to check with @mbautin or @spolitov for more details.

cc @deeps1991 also if above makes sense

[es1024]

Added with 6454f01.