Daemon RPC: high_height_ok req boolean field /getblocks.bin

[j-berman]

Behavior before: when req.start_height > chain tip, response fails and the client is dropped and blocked

Behavior after: when req.high_height_ok && req.start_height > chain tip, the server returns a successful empty block response that includes the chain height

This is useful when firing parallel requests to scan the chain and the client doesn't initially know what the chain tip is. This avoids the client getting itself dropped when firing too high of a request.

The reason I implemented this new optional high_height_ok field rather than changing the default behavior to return a successful response when the request includes too high of a height is to maintain backwards compatibility with clients that perhaps currently rely on a failure response when requesting too high a height. Perhaps this is overkill and I could be convinced that making "high height ok" the server's default behavior (and not implementing the request field) is the better call.

Used in the Seraphis lib async scanner: UkoeHB#23

[vtnerd]

This seems ok, but I'm not seeing why it would be needed by the new async scanner. Why won't the scanner know the top block height?

[j-berman]

E.g. you re-open your wallet and it's 3 blocks behind the chain tip. Client fires 10 parallel requests:

req 0 start height: chain tip - 3
req 1 start height: (chain tip - 3) + 20
req 2 start height: (chain tip - 3) + 40
...
req 9 start height: (chain tip - 3) + 180

Technically reqs 1-9 are unnecessary, but the client won't know this until it gets its first response. This approach also avoids the need to make a round trip to the server to request the current chain tip before starting to scan.