Pruned node support

[RCasatta]

          Fwiw the following rather horrifying hack "works":

let bin_bh: [u8; 32] = hex::FromHex::from_hex("deadbeef...").unwrap();
let mut next = BlockHash::from_raw_hash(sha256d::Hash::from_byte_array(bin_bh));

(replacing the above linked definition of next ; of course you have to add the use statement: use bitcoin::hashes::{hex, sha256d, Hash};)

... where deabeef.. is the big-endian encoding of a block hash. But "works" with caveats:

• the block hash used there should be that of the first block in your database, identifiable with bitcoin-cli getblockchaininfo (but I guess it changes over time, so you need to have bitcoind not running)
• defining start_height and end_height doesn't work (at least, in my test), because I think with this hack it treats your first block as literally block 1 (or 0, whatever).

Still, it does output the data I wanted from a filter, so, it (barely) passes the bar of at least being worth reporting.

_Originally posted by @AdamISZ in https://github.com/RCasatta/blocks_iterator/issues/83#issuecomment-1992684079_

[AdamISZ]

For what it's worth, this would indeed be very useful for a project like this one I'm working on, because the idea is that a bunch of users (things like Joinmarket, Lightning perhaps) might want to create snapshots of keysets from the blockchain with generally agreed filters, and then run zero knowledge proofs of token validity w.r.t. that keyset. To do that each user (or let's say "each first class user"!) needs to reconstruct the keyset. Perhaps we could and should just expect all such users to run unpruned nodes, but on the other hand in e.g. Joinmarket that isn't currently needed, and I got the impression from my, quite crude, understanding of how this tool works, that it probably wouldn't be that hard to fix it to work with pruned.