Enable IndexV2

[cpubot]

Problem

The current blockstore index type, backed by a BTreeSet, suffers from performance issues in serialization / deserialization due to its dynamically allocated and balanced nature. See #3570 and #3900 for context.

Summary of Changes

A follow up of #3900, this enables IndexV2 as the primary read/write target for the blockstore's Index type.

Other notes

In a follow up PR, I'll introduce a test case that exercises the fallback deserialization logic, where data in the blockstore is written as IndexFallback, deserialized as such, and recovered as Index.

[cpubot]

This branch running on my dev node against another on mnb (no nuking of ledger necessary)

my node before/after

[steviez]

In a follow up PR, I'll introduce a test case that exercises the fallback deserialization logic, where data in the blockstore is written as IndexFallback, deserialized as such, and recovered as Index.

I'm inclined to say that we should include the test in this PR. Since this PR is now writing the new format (and should land in v2.2), the test you described sounds similar to what we'd encounter in the v2.1 to v2.2 upgrade scenario if I'm not mistaken:

• Node is running with v2.1 and writing BTreeSet
• Node is stopped and upgraded to v2.2
• Node is restarted with v2.2 and reads the BTreeSet index type for a slot that was written when it was running v2.1

[bw-solana]

I would typically recommend staging multiple small PRs to:

1. change the name from Index --> IndexV1 and setup the pub type Index = IndexV1;
2. Switch the mapping so pub type Index = IndexV2;

However, this is small enough I'm not going to gate on it.

Regarding naming, IndexLegacy makes it more clear that this type is being phased out, which is good. But then compared to ShredIndexV2 it feels like we're mixing 1/b/iii. Especially if we ever add a ShredIndexV3.

I also agree with @steviez that we should make sure we have the unit tests for the conversions/fallbacks in place as part of this PR (or before it)

[cpubot]

Regarding naming, IndexLegacy makes it more clear that this type is being phased out, which is good. But then compared to ShredIndexV2 it feels like we're mixing 1/b/iii. Especially if we ever add a ShredIndexV3.

Good call, this is definitely a better naming scheme.

[bw-solana]

LGTM

[steviez]

Code looks good. One additional thing that I think would be nice to add is an entry to the CHANGELOG. Namely, something similar to what is being added in #4600 like this:

• Blockstore Index column format change
  • The Blockstore Index column format has been updated. A Blockstore written to with v2.2 is compatible with v2.1 and incompatible with v2.0 and older

I think under the "Breaking" section (which that PR introduces) is the right place. That other PR should land very shortly, so the hope is maybe you could rebase on top of it + add the extra line to the changelog then

[steviez]

LGTM