YT-27264: Per-tag ordering for transactions on master

Currently all Sequoia transactions are marked as strongly ordered. This means that master runs commit actions in order of commit timestamps of transaction. This is a desired behaviour. However, let's think about two transactions, one modifying node N, and the other modifying chunk C. If C does not belong to N, then it's not strictly necessary to order commits of transactions, but we do it anyway, which costs a lot of time. This PR addresses that following issue by introducing ordering tags.

Important changes in this PR:
1. Introduce strong ordering manager to transaction supervisor. Now, if transaction has strong ordering tags specified, and another transaction has intersecting strong ordering tags, then they will be committed **on master** in order of commit timestamps. This somewhat mirrors the sequencer used by tablets. Currently only two tags are supported.
2. Sequoia transactions can be selectively waited for. When starting a transaction, one can specify barrier tags. Transaction manager now has an API, which allows to wait until transactions with a specific tag moves from prepared state to committed. Previously similar logic was written in a transaction supervisor. This is mostly used internally when committing Sequoia transactions, to ensure that requests are not run over stale data. For details see `WaitUntilPreparedTransactionsFinished`.
3. Setting strong ordering tags on commit now forces 2PC even for commits with a single participant.
4. Testing config related to barriers is moved from static transaction supervisor config to a dynamic transaction manager config.

Hopefully due to new barrier system (2) tracking transaction state, rather than commit state, an average barrier wait time will be lowered.

Please note that strong ordering tags do not work with `ECommitMode::Lazy`!
commit_hash:64b30217c1db27cec4a8e5ca053e5c2a44341d56

0 files changed, 0 insertions, 0 deletions