[base-node] Optimise pruned UTXO sync streaming protocol

[sdbondi]

Description

Streams a pruned UTXO set to a client. Each block boundary (given by the
header) is punctuated by a deleted MMR difference bitmap.

Replaces the previous sync_rpc method, which has been removed and so,
this PR is not backward-compatible.

Motivation and Context

Continues from changes in #2847.
There are a few other performance optimisations still to be made for horizon sync.

How Has This Been Tested?

Manually tested. Sync took 15m.

Checklist:

• I'm merging against the development branch.
• I have squashed my commits into a single commit.

[philipr-za]

LGTM

[SWvheerden]

Looks good.
I think the fn synchronize_outputs( is a bit more complex.
I also don't like the use of the word block in the logs for the pruned mode sync. This is technically incorrect and I think confusing as we never download blocks. I flag some but not all uses

[stringhandler]

Happy with the approach, but I am concerned about the single DeletedBitmap and can't see how it maps to the MMR hash in the header in all cases.

[sdbondi]

@mikethetike The deleted difference bitmap is sent at the end fo each block boundary (as given by output mmr size).
so : UTXO_1 , UTXO_2, ... , deleted diff indexes (signals that we should check the MMR/end of the block)

The only difference to what is sent from before is that instead of many difference bitmaps Vec<Bitmap> I send one union bitmap containing all the newly spent UTXO indexes, these are equivalent in the data they contain. On the client side, we take the previous blocks bitmap and union the differences and check the MMR. So in effect, nothing has changed from before except it's a little smaller over the wire and only 1 bitmap needs to be serialized.

EDIT:
The way fetch_utxos_by_mmr_position works is very confusing, but it will always give you the difference in deleted MMR index differences between h - 1 and h where h is the header heights where start, end index overlap - even if start does not start at the beginning of a block. I don't think we really need this mapping now that we have the output_mmr_size in the headers - outputs should simply be indexed by the integer key mmr_position. Fetching the deleted difference could probably be another call, riffing but something like fetch_spent_txo_diff_bitmap_at(height: u64)

EDIT2:
I think that the biggest perf optimisation after this will be syncing kernels and UTXOs concurrently followed by building an accumulated commitment while syncing for use in the finialise step

[stringhandler]

Ok, happy