Label generator for a table under exactly-once mode. The generator should guarantee the
uniqueness of the label across different flink jobs, different tables in one job, different
subtasks for a table in one job, and different transactions in on subtask. The label is
in the format {labelPrefix}-{table}-{subtaskIndex}-{id}, and it will be unique because
1. labelPrefix is unique across different flink jobs, so there is no conflict among flink
jobs. Note that the uniqueness of labelPrefix should be guaranteed by users.
2. the table name is unique in a database of StarRocks, and the label only need to be unique in
the scope of a database. so the label can be unique even if write to multiple tables in a job
3. use subtaskIndex to make it unique across subtasks if the sink writes parallel
4. use incremental id to make it unique across different transactions in a subtask
The reason why we design this generator for exactly-once is to clean up lingering transactions.
Compared to at-least-once, exactly-once will not abort the PREPARED transactions when the job
failovers or exits because it's 2PC mechanism. Some of those PREPARED transactions may be in a
successful checkpoint, and will be committed when the job restores from the checkpoint, but some
of them are just useless, and should be aborted, otherwise they will be lingering in StarRocks
until timeout which maybe make StarRocks unstable, so we should try to abort these lingering
transactions when the job restores. The key is to find those lingering transactions, and we achieve
it by generating labels according to certain rules, storing the label generator information in
checkpoint, and constructing labels of possible lingering transactions when restoring from the
checkpoints. First, each label has an incremental id, and when checkpointing, the labels with ids
less than nextId must be successful, and ids for lingering transactions must be no less than nextId.
Secondly, make a snapshot ExactlyOnceLabelGeneratorSnapshot for the generator when checkpointing,
and store it in the state. Thirdly, when restoring from the checkpoint, we can get the nextId, build
labels with those ids no less than nextId, and , query label state in StarRocks, and abort them
if they are PREPARED.