Return multiple blocks for `SyncNotes`

[Mirko-von-Leipzig]

SyncNotes gRPC endpoint currently returns notes from the next applicable block only. This means that syncing notes can take many requests.

Change the endpoint to return as many blocks worth of notes as possible, i.e. a Vec of the current response, while staying within the ~4MB payload limit.

This could be changed at the RPC component only, where it internally does multiple trips to the store until the batch is full. However, I would prefer if we perform this work on the store side and minimize the gRPC trips involved. This also keeps the RPC and store gRPC method definitions aligned.

[igamigo]

One thing worth noting: currently, the SyncNotesResponse contains an authentication path of the matched block header. If multiple blocks are going to be returned in the same response by naively pushing responses into a list, some (probably a decent amount?) of bandwidth would be wasted in duplicate nodes. Related to this, in the client we do not use this merkle path at all - I believe it is mostly a remainder of the endpoint from when it was not being used as part of the sync state (i.e., before the original endpoint was fully segregated), so in general I wonder if this should be removed entirely. Though maybe something else uses it?

Additionally, conceptually I think there might be more improvements that could potentially be implemented. For example, SyncMmr could also be batched this way (basically contain deltas/nodes for multiple updates).

So I wonder if the following changes should be made:

• SyncNotes returns a list of (BlockHeader, Vec<NoteInfo>) as well as the chain tip number. It does not return merkle paths anymore
• SyncMmr takes a from_block_num and a list of block_nums to sync to

Then the client can sync like so:

• Calls SyncNotes from current sync height to chain tip. A single roundtrip may return many block headers (matching_blocks) and matched notes for each of those. It also needs to return the chain tip header when that is reached
• Calls SyncMmr starting the current sync height, and passing the list of block numbers that we get from the SyncNotes response ([..matching_blocks, chain_tip])
• Applies MmrDelta to the local MMR, adds the corresponding block header to the MMR and repeats until all batches are done. Internal auth nodes that emerge are persisted

There is also a client-side optimization above where we consumption-check the notes and discard the blocks from matching_blocks before calling SyncMmr to avoid getting more deltas than we need to.

I think that optimizes bandwidth, roundtrips and maybe processing, but I do have some open questions:

• Not entirely sure how compute intensive it is to get an MmrDelta, but instinctively it doesn't seem like it should be too much (not more than walking a block auth path?)
• Maybe the better alternative is to deduplicate the auth nodes from all the SyncNotesResponse merkle paths? There are some race conditions where the MMR advances in between SyncNotesResponses, and so the paths relate to different MMR forests, but the client could take care to trim the paths where necessary