The `bridgetree-v0.2.0` tag was created with respect to an invalid
repository state, which did not actually contain the `bridgetree`
sources after they were factored out from the `incrementalmerkletree`
crate.
The choice to use an initial checkpoint as an anchor for removals in
`unmark` operations produced an awkward situation where it was necessary
to choose a checkpoint identifier just to construct an empty tree. This
removes that decision in favor of eagerly removing data if there is no
checkpoint to tie the removal to.
The primary implementations of `ShardStore` will be constructing
owned values from an underlying persistence layer, and it is not
possible to return a reference to an owned value.
The structure of the `incrementalmerkletree` and `bridgetree` types has
not historically been stable, and as such it is not appropriate to
automatically derive serialization for these types.
This fixes a minor compatibility issue with respect to possible
deserialization of the `incrementalmerkletree-0.3.0` `MerkleBridge`
type. It is not necessary to track a marked leaf in the current
bridge *unless* the marked position is the bridge's starting position
and the prior bridge ended at a checkpoint.
This removes the `mark` function from the `tree` interface, in favor
of always appending nodes as marked, as that's what's needed in
practice, rather than the ability to mutably mark the latest position at
arbitrary states of the tree.
This removal does mean that a few patterns of interleaved mark and
checkpoint operations are no longer being tested in the shared test
suite; however, such interleaving of operations is not something that
we should need to support anyway.
This change exposed an inconsistency in how `BridgeTree` and
`CompleteTree` were tracking `Mark` operations, which has now also been
fixed.
The behavior of the "unmark" operation has been simplified, such that it
now ensures that a marked node will be made eligible for garbage
collection when the checkpoint for the tree state in which the mark was
forgotten rolls off the back of the checkpoint queue.
The transitive dependency we have on `unarray` is forcing this update.
Also, update CI actions to eliminate dependencies on the unmaintained
`actions-rs` Rust CI tools.
Kris Nuttycombe