Implement a lotus-shed command to garbage collect all the indices not available in the state store

[akaladarshi]

Checklist

• This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the lotus forum and select the category as Ideas.
• I have a specific, actionable, and well motivated feature request to propose.

Lotus component

• lotus daemon - chain sync
• lotus fvm/fevm - Lotus FVM and FEVM interactions
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt/WinningPoSt)
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

What is the motivation behind this feature request? Is your feature request related to a problem? Please describe.

Before unifying all the indexes (msg, tx, event) into a single DB, it’s crucial to garbage-collect (GC) any indices that are no longer referenced in the state store. This step will ensure that pruned or obsolete data isn't carried over during the migration, leading to a cleaner and more efficient database.

Describe the solution you'd like

Introduce a lotus-shed command that performs garbage collection on all indices not referenced by the current state. This command should effectively remove unnecessary indexes, optimizing the database before the unification of the indexes.

Additional context

This has been discussed here as well and it will be helpful to @aarshkshah1992, as he is working on unifying the DB for the indexes.

[rvagg]

@akaladarshi @aarshkshah1992 we need to figure out what the most efficient way to figure out what our oldest state tree is. We have all the tipsets in the chain store but I suppose if we were to iterate over the state roots and try and load just the state root block then we'd eventually find one that doesn't load.

[aarshkshah1992]

@rvagg

As discussed offline, I think the best approach here is for the user to specify "start with tipset X and gc everything backwards till epoch Y". That atleast enables majority of our users who run a snapshot synced node with splitstore enabled (sync once -> then "run forever")to GC events they know they don't have the state for anymore (these users usually retain state for the last 1 or 2 days).

Once we have this in place, we can think about GC strategies for other use cases.

[BigLep]

This is subsumed by work happening in #12453