v1.18 hash mismatch

[willhickey]

Problem

#34865 introduced a hash mismatch

I've been reproducing on testnet slot 249712853

`$ solana-ledger-tool verify --ledger ledger --halt-at-slot 249712853`

Good    bank frozen: 249712853 hash: GJByGhuj3Uxga474oPkv9tbyuepxKniVKBVWHoNgDKzz
Bad     bank frozen: 249712853 hash: 5pkAHGDTCx9MLURD7NyheozmbMak2M8rZeQJXcvRCP4D

#35007 reverts the change in v1.18. Master presumably has the mismatch too but I haven't tested that yet.

Proposed Solution

[apfitzge]

https://github.com/solana-labs/solana/pull/34865/files#diff-ed47b4a0198313377e091bb3957bbbc63d937805426d1b2b6de39d0a50d32a0cR6673

I think getting it off the fee generator was incorrect here.
Seems like the right way would probably be to get it off of the blockhash queue for the parent hash

[tao-stones]

https://github.com/solana-labs/solana/pull/34865/files#diff-ed47b4a0198313377e091bb3957bbbc63d937805426d1b2b6de39d0a50d32a0cR6673

I think getting it off the fee generator was incorrect here. Seems like the right way would probably be to get it off of the blockhash queue for the parent hash

very likely, trying to repo

[tao-stones]

https://github.com/solana-labs/solana/pull/34865/files#diff-ed47b4a0198313377e091bb3957bbbc63d937805426d1b2b6de39d0a50d32a0cR6673

perhaps due to testnet genesis sets target_lamports_per_signature: 0, so the fee_structure derived form it would have 0 lamports-per-signature. Going to modify it to see if makes difference...

[tao-stones]

A bug is introduced here: when the lamports_per_signature param is zero, it used to wipe out entire fee to zero; the PR made it only sets signature_fee to zero, priority fee was not cleared.

But testing with a quick patch to reverse logic produced yet another different bank hash for 249712853. Still looking...

[tao-stones]

proposed a fix at #35012. Tested with testnet snapshot to confirm hash matches; Going to do test with mainnet ledger too