Computes, sends, receives and compares ACS commitments

In more detail:

• The class computes the participant's ACS commitments (for each of the participant's "counter-participants", i.e., participants who host a stakeholder of some contract in participant's ACS). The commitments are computed at specified (sequencer) times that are configured by the domain and are uniform for all participants connected to the domain. We refer to them as "commitment ticks". The commitments must be computed "online", i.e., after the the state of the ACS at a commitment tick becomes known.
• After the commitments for a tick are computed, they should be distributed to the counter-participants; but this is best-effort.
• The class processes the ACS commitments from counter-participants (method processBatch):
• it checks that the commitments are properly signed
• it checks that they match the locally computed ACS commitments
• The class must define crash recovery points, such that the class itself combined with startup procedures of the node jointly ensure that the participant doesn't neglect to send its ACS commitments or process the remote ones. We allow the participant to send the same commitments multiple times in case of a crash, and we do allow the participant to not send some commitments in some edge cases due to crashes.
• Finally, the class supports pruning: it computes the safe timestamps for participant pruning, such that, after pruning, non-repudiation still holds for any contract in the ACS

The first four pieces of class functionality must be appropriately synchronized:

• ACS commitments for a tick cannot be completely processed before the local commitment for that tick is computed. Note that the class cannot make many assumptions on the received commitments: the counter-participants can send them in any order, and they can either precede or lag behind the local commitment computations.
• The recovery points must be chosen such that the participant computes its local commitments correctly, and never misses to compute a local commitment for every tick. Otherwise, the participant will start raising false alarms when remote commitments are received (either because it computes the wrong thing, or because it doesn't compute anything at all and thus doesn't expect to receive anything).

Additionally, the startup procedure must ensure that:

• processBatch is called for every sequencer message that contains commitment messages and whose handling hasn't yet completed sucessfully
• publish is called for every change to the ACS after com.digitalasset.canton.participant.store.IncrementalCommitmentStore.watermark. where the request counter is to be used as a tie-breaker.

Finally, the class requires the reconciliation interval to be a multiple of 1 second.

The commitmentPeriodObserver is called whenever a commitment is computed for a period, except if the participant crashes. If publish is called multiple times for the same timestamp (once before a crash and once after the recovery), the observer may also be called twice for the same period.