Tracker for submission, backed by a SubmissionTrackerStore.

The purpose of this tracker is to detect replayed requests, and allow the participant to emit a command completion only for genuine requests that it has submitted. A request R2 is considered a replay of a request R1 if they both contain the same transaction (root hash), and R2 has been sequenced after R1 (its requestId is later).

The protocol to use this tracker is:

- At the beginning of Phase 3, the participant must first call the tracker's register() method for every incoming confirmation request, in sequencing order. This returns a Future, which must be kept until the completion of the request.

- Further during processing of Phase 3, when further information about the request is obtained, the participant must either:

• call cancelRegistration() when a request is deemed invalid or does not contain root views (and therefore was not submitted by this participant), or
• call provideSubmissionData() with information about the submission.

- During phase 7, when finalizing the request, the participant must use the result of the Future returned during registration to determine whether the request requires a command completion.

Calling the methods in a different order than described above will result in undefined behavior. Failure to call either cancelRegistration() or provideSubmissionData() after calling register() for a request may result in a deadlock.