erasure doesn't tolerate forks

[rob-solana]

data blobs have PoH information that allows us to figure out who the parent blob is, in the case of a fork (i.e. 2 different blobs at the same blob_idx/ledger height).

possible fixes:

• move FEC into the blobs themselves, so that PoH can (maybe?) be used to put the blobs in order before calling recover()
• use blob_id (i.e. leader that issued the blob) to group blobs by fork instead of PoH
• try erasure blobs with multiple PoH tracks

It's possible that erasure is generally incompatible with forks

[aeyakovenko]

@rob-solana, won’t all forks be virtual?

[rob-solana]

these cases are of concern, I think

1. leader schedule partition, where 2 leaders think they're next
2. slashable leader (i.e. 2 different data blobs for the current entry height)

[aeyakovenko]

@rob-solana how will two leaders be next? L1 and l2 have different start points

[rob-solana]

in a partition that lasts long enough for a new leader schedule?

[aeyakovenko]

@rob-solana just fail those :). schedule is decided at count X, active at count Y. that difference could be 24 hours

[rob-solana]

depends on #1433 being fixed

[rob-solana]

this rolls into #1717, is essentially a duplicate, so closing here