IGNITE-24384 Support write intent switches within colocation logic

[rpuch]

https://issues.apache.org/jira/browse/IGNITE-24384

[sanpwc]

Too many similar entities MutablePartitionEnlistment, FinishingPartitionEnlistment, EnlistedPartitionGroup with some carelessness in javadocs:

• EnlistedPartitionGroup javadoc claims that it's Partition enlistment together with partition group ID, meaning tableIds = Partition enlistment.
• MutablePartitionEnlistment is primaryNode + consistencyToken + tableIds

Do you have any ideas of how to make MutablePartitionEnlistment, FinishingPartitionEnlistment, EnlistedPartitionGroup cleaner, probably decreasing the number of classes?

[rpuch]

These 3 represent similar information ('partition enlistment information') at different times in different contexts. They all relate to some groupId (but in 2 cases groupId is stored externally, as map key, and in the last case it's stored inside) and they all have tableIds (in first case it's mutable, in other cases it's not).

1. MutablePartitionEnlistment (which I've just renamed to OngoingTxPartitionEnlistment to make it more clear what it is) is used to track enlistment information for a partition (which groupId is stored externally) while the transaction is still running, before it is finished; so it needs to know its primary replica (in the form of ClusterNode, not just name) and enlistment token
2. FinishingPartitionEnlistment represents the same information when the transaction is being finished and when tx cleanup happens. At this stage, tableIds doesn't need to be mutable anymore, and token is not needed; the primary node is still needed but it can be represented as a name.
3. EnlistedPartitionGroup represents this 'thing' stored in TxMeta (and in tx state storage). Primary information is not needed anymore, but groupId has to be stored explicitly. Even if we represented collections of EnlistedPartitionGroup as maps from groupIds to the remaining enlistment information, we wouldn't be able to reuse FinishingPartitionEnlistment because we don't primary node name it contains. (Technically, we could, but it would be ugly). On the other hand, I don't look the idea to remove EnlistedPartitionGroup and just use maps from groupIds to tableIds everywhere we use collections of EnlistedPartitionGroup (this would be hide an entity)

To sum up: I wasn't able to invent any way to remove any of these entities. I named them to make first and second look alike (as they are really close) and third to be a little different (as it's context is a bit different). If you have any ideas on how to improve this, please share them.

I also updated javadocs on the classes to decrease possible confusion.

[sanpwc]

[removed]