feat(rpc): SyncNotes endpoint

[Mirko-von-Leipzig]

Closes #409.

The implementation is essentially a clone of SyncState with some parts left off. Which makes me believe I've misunderstood the assignment :)

[bobbinth]

Looks good! Thank you! I left some comments inline.

Overall, I think this looks right - but there are two questions I have and probably @igamigo and @tomyrd are the ones best positioned to answer them:

• Do we need to include the transactions field in the response (similar to how we have it for state sync). It seems to me that we don't - but I also haven't thought it through completely.
• Would the client be able to use the MMR info returned from this endpoint to update its MMR correctly? On the client side, this will probably work somewhat differently from how state sync works because this endpoint would be invoked at the time when the client's MMR is "in the future" compared to the requested data.

[igamigo]

Do we need to include the transactions field in the response (similar to how we have it for state sync). It seems to me that we don't - but I also haven't thought it through completely.

I don't think this is necessary.

Would the client be able to use the MMR info returned from this endpoint to update its MMR correctly? On the client side, this will probably work somewhat differently from how state sync works because this endpoint would be invoked at the time when the client's MMR is "in the future" compared to the requested data.

After reviewing it a little bit, I think returning a Merkle path here is better and makes for a cleaner handling of the response on the client side. More so if we assume the client is going to call the endpoint after having synced past the block of the note's creation.

[bobbinth]

After reviewing it a little bit, I think returning a Merkle path here is better and makes for a cleaner handling of the response on the client side. More so if we assume the client is going to call the endpoint after having synced past the block of the note's creation.

Yes - I came to a similar conclusion. Basically, we just need the MmrProof for the returned block header. And we can get this directly from the in-memory MMR.

[bobbinth]

Looks good! Thank you! I left a few more comments inline.

[tomyrd]

LGTM! I agree with what @igamigo said, we will need to test it in the client but I think it will work.

[bobbinth]

Looks good! Thank you! I left a few more minor comments inline. After these are addressed we can merge.

[bobbinth]

All looks good! Thank you!