In this case, we need to keep them around during the revert.

We do this by pre-pending + to the list.

When doing reverts, we do not delete raw multihashes that already existed.

This happens only if the user had both the CidV1 and  the CidV0 for something.

This commit ensure that we traverse all the CIDs in the pinset and MFS trees
and revert them to cid-based addressing in the datastore when the migration is
reversed. This addresses the problem when a user has added new CIDv1 pins or
modified MFS with CIDv1 content before reverting the migration. In that case,
those new multihash-addressed blocks would stay as such and while they could
potentially still be read, they would be swiped out by GC in the older version
of the code.

Additionally, there are corner cases when content is added with both CIDv1 and
CIDv0 (but the same multihash). These were partially addressed already by
keeping track of CIDv0 blocks that existed already for CIDv1 equivalents, and
by some logic during reverts, to handle blocks referenced from several
CIDv1s. However, things like adding CIDv1 and CIDv0 equivalent blocks to the
pinset after migration would not be handled properly.

To address all these issues, and simplify, we have opted to not delete any
raw-multihash-addressed block during revert. We convert as much as we can to
CIDv1 (using the backup file and the pinset/mfs trees), but otherwise leave
all the blocks. This simplifies the code and makes reverts more
memory-friendly at the expense of extra disk space.

As a final reminder, CIDv1s are not the default. We can expect that in the
general case, people have content that is CIDv0 addressed and requires no
action whatsoever in both migrating forward and backwards.

They are fine as they are.

…-vendored

Migration 11-12: vendor dependencies