Add debugging fields to archiver errors

[teor2345]

We had a report of archiver errors on a timekeeper:

I noticed a timekeeper in an endless restart loop and always throwing this panic
archival-node-1 | 2025-02-07T17:05:49.143589Z INFO Consensus: sc_consensus_subspace::archiver: Resuming archiver from last archived block last_archived_block_number=2358
archival-node-1 | thread 'tokio-runtime-worker' panicked at /code/crates/sc-consensus-subspace/src/archiver.rs:713:14:
archival-node-1 | Incorrect parameters for archiver: InvalidBlockSmallSize { block_bytes: 874, archived_block_bytes: 1751094 }
archival-node-1 | note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Things i did:

• I switched cores for the timekeeper thread to run on (no luck),
• I then removed the timekeeper flags and tried to start it but no luck.
• I then removed the timekeeper flags and wiped the node and it started.

Looking at the code, there's nowhere that changes the segment header (last archived block) or block data. So this seems like corruption in the segment or block stores due to overclocking. This PR adds debugging fields to archiver instantiation errors, to help diagnose similar errors in future.

It also adds a PartialEq implementation for Archiver, which simplifies existing tests. I plan to use it in future archiver object mapping or retrieval tests. (Unfortunately this impl can't be cfg(test), because it's used in integration tests.)

Finally, this PR changes an incorrect (but harmless) BlockNumber type in that error to u32.

Code contributor checklist:

• I have read, understood and followed contributing guide

[nazar-pc]

Semantically this doesn't really make a lot of sense IMO, which is why tests did not use it. There should be no need and it does not make sense to compare two archiver instances.

[nazar-pc]

Not sure how useful this actually is, we already have this information on higher level.

I'd probably replace "Incorrect parameters for archiver" panic with an error message that also logs the whole last_segment_header, which will have the same effect.

[nazar-pc]

Also test seems to fail due to prev_segment_header_hash check that was initialized to zero bytes, but the thing is, we do not actually care about it, we care about bytes. Previous version of the test explicitly checked just bytes, partially acting as self-documentation by clearly describing things that are relevant to the test and ignore those that are not.

[teor2345]

Since you’ve asked me to rewrite almost the whole PR, I think it would be less confusing to close this one, and open another one if I get time.