Data column custody info

[eserilev]

Issue Addressed

#7647

Proposed Changes

Introduces a new record in the blobs db DataColumnCustodyInfo

When DataColumnCustodyInfo exists in the db this indicates that a recent cgc change has occurred and/or that a custody backfill sync is currently in progress (custody backfill will be added as a separate PR). When a cgc change has occurred earliest_available_slot will be equal to the slot at which the cgc change occured. During custody backfill syncearliest_available_slot should be updated incrementally as it progresses.

Note that if advertise_false_custody_group_count is enabled we do not add a DataColumnCustodyInfo record in the db as that would affect the status v2 response.
(See comment #7648 (comment))

If DataColumnCustodyInfo doesn't exist in the db this indicates that we have fulfilled our custody requirements up to the DA window.
(It now always exist, and the slot will be set to None once backfill is complete)

StatusV2 now uses DataColumnCustodyInfo to calculate the earliest_available_slot if a DataColumnCustodyInfo record exists in the db, if it's None, then we return the oldest_block_slot.

[jimmygchen]

@eserilev Nice, this looks great overall!
The main comment is that we should probably store the effective epoch/slot instead of the current slot - this is when the new CGC is applied in DA check.

[eserilev]

@michaelsproul have a question re: schema version increment

This PR introduces a new column, but the database will only contain a value for this column if a recent cgc change has occurred and custody backfill hasn't finished. In that case, is a version increment necessary? An upgrade should be a no-op. A downgrade might also be a no-op because we should not delete this column from the db if a record exists as that would break our ability to track the recent cgc change

[michaelsproul]

@eserilev I think a schema update is cleanest, especially if we go with my idea from here to make the DataColumnCustodyInfo stored always (when Fulu is enabled): #7648 (comment)

As Jimmy pointed out via DM, a DB downgrade that deletes the value would also guard against starting up with a stale value in the scenario where we downgrade and then re-upgrade. I.e. run the new version, downgrade, run the old version for a bit, upgrade again --> end up using the stale value from the first time we ran. However this is probably not super relevant because by the time we are running Fulu on real networks, downgrading to a prior schema should not be allowed (we could even add a check in the downgrade that only allows downgrading if fulu_fork_epoch.is_none()).

[michaelsproul]

The schema_stability test will also need an upgrade for the new column. And we could add an assert about the DataColumnCustodyInfo so that future changes to it (which are probably kinda likely) are caught.

[mergify]

Some required checks have failed. Could you please take a look @eserilev? 🙏

[jimmygchen]

Hey @eserilev
Looking good, i think we can merge this soon - I've left a few comments, the main one is the effective_epoch comment that needs fix I think.

[jimmygchen]

LGTM!