Define and implement MinerPreCommitInfoV9 schema and extraction

[frrist]

Description

The on-chain state of miner PreCommit Infos has changed: Previous->Current. Lily must incorporate tracking of this new information.

Acceptance criteria

• The current MinerPreCommitInfo schema will cease to populate for all miner PreCommit infos after actors v8.
• Create a new schema/model MinerPreCommitInfoV9 to track new data contained in miner PreCommit infos for all miner actors v9 and above.
  • The new schema will follow similar indexing patterns to the previous and will contain new data contained in miner precommit infos.

New Schema Definition:

CREATE TABLE miner_pre_commit_infos_v9(
    height bigint NOT NULL,
    state_root text NOT NULL,
    miner_id text NOT NULL,
    sector_id bigint NOT NULL,
    
    pre_commit_deposit numeric NOT NULL,
    pre_commit_epoch bigint NOT NULL,
    seal_proof numeric NOT NULL,
    sealed_cid text NOT NULL,
    seal_rand_epoch bigint NOT NULL,
    expiration_epoch bigint NOT NULL,
    deal_ids bigint[], -- new field
    unsealed_cid text -- new field

/* deprecated
    verified_deal_weight numeric NOT NULL,
    is_replace_capacity boolean,
    replace_sector_deadline bigint,
    replace_sector_partition bigint,
    replace_sector_number bigint,
*/
);

Extraction of this new data will follow the same pattern as previous extraction and will include the new fields in the extracted model.

[frrist]

An alternative to storing the deal_ids array in this model would be to create a second model miner_pre_commit_deals that tracks with dealIDs are in which precommits, similar to how miner_sector_deals behaves.

[placer14]

Let me know if I'm assuming wrong about this, but the /* deprecated */ section will not be present in the v9 table, it's just there to show that it was in the orig (v1) table, right?

An alternative to storing the deal_ids array in this model would be to create a second model miner_pre_commit_deals that tracks with dealIDs are in which precommits

I need to spend some time to understand the protocol change here to see whether the use case would prefer one approach versus another. Impacting items:

• I assume not, but to be sure, would precommit info's dealID array content ever change (outside of a reorg)?
• How large is this array likely to be? (Seeks into a large array are expensive, especially so for queries which will not always be able to use cached responses depending on the query plan the server creates.) I might avoid inline array if N>100 for an int8 (bigint) dealID.

Otherwise, this looks good to me! 🤝

[placer14]

Here are some recommended indices:

Existing:

• height (ASC),miner_id,sector_id,state_root btree
• height DESC btree

Recommended:

• sealed_cid hash
• unsealed_cid hash