Constraints on `ShardStore::CheckpointId` are inconsistent between `ShardStore::update_checkpoint_with` and `CachingShardStore`/ `MemoryShardStore`

[A-Manning]

CachingShardStore and MemoryShardStore both require a ShardStore::CheckpointId to impl Ord. However there is a further, undocumented constraint that CheckpointIds for any two Checkpoints are ordered by the checkpoint positions.

IIUC, this means that any CheckpointId used for CachingShardStore/ MemoryShardStore must be of the form

#[derive(Eq, Ord, PartialEq, PartialOrd)]
struct CheckpointId {
    position: Position,
    ...
}

ShardStore::update_checkpoint_with can potentially mutate the checkpoint corresponding to a specified CheckpointId. This can change the checkpoint's position, and therefore the corresponding CheckpointId. The user always needs to account for this when implementing ShardStore::update_checkpoint_with.

It would be best to provide a CheckpointId struct for use with CachingShardStore and MemoryShardStore, ie.

#[derive(Eq, Ord, PartialEq, PartialOrd)]
struct CheckpointId<T> {
    position: Position,
    tag: T
}

impl<H: Clone, C: Clone + Ord> ShardStore for MemoryShardStore<H, C> {
    type H = H;
    type CheckpointId = CheckpointId<C>;
    type Error = Infallible;
    ...
}

impl<S> ShardStore for CachingShardStore<S>
where
    S: ShardStore,
    S::H: Clone,
    S::CheckpointId: Clone + Ord,
{
    type H = S::H;
    type CheckpointId = CheckpointId<S::CheckpointId>;
    type Error = Infallible;
    ...
}