`SyncChainMmr` block range start is exclusive

[TomasArrachea]

The SyncChainMMr block range start is treated as exclusive, but the proto docs are confusing:

node/proto/proto/rpc.proto

Lines 510 to 513 in 39f19f1

	message SyncChainMmrRequest {
	// Block number from which to synchronize (inclusive). Set this to the last block
	// already present in the caller's MMR so the delta begins at the next block.
	fixed32 block_from = 1;

We should change the implementation so it's effectively inclusive, and aligned with the rest of the endpoints.

[kkovaacs]

Instead of "fixing" this I'd suggest an alternative:

• We should rename block_from to current_block_height. We're expecting the client to tell the node which height it is synced up to.
• Remove upper_bound and always return information up to the committed tip.

[bobbinth]

Remove upper_bound and always return information up to the committed tip.

Thinking more about this (after the offline sync), this should probably work. The only thing that may be good to do is make sure that the client has can use the returned data to easily figure out what is the last proven block. This can be done by including the number of the last proven block in the response.

We also may want to include extra info into the response to make sure the client could use the last proven block as a transaction anchor. This may be as simple as including the MMR delta between the last proven and last committed block - though, I haven't thought too much about it.

[TomasArrachea]

We also may want to include extra info into the response to make sure the client could use the last proven block as a transaction anchor. This may be as simple as including the MMR delta between the last proven and last committed block - though, I haven't thought too much about it.

In addition to this, we could also include the MMR path of the committed chain tip block, so that the client can validate the returned block header. This was discussed recently in 0xMiden/miden-client#1887 (comment)