feat: use channels for chainsync client requests for results and allo…

[rakshasa]

…w simultaneous GetCurrentTip requests

[agaffney]

@rakshasa if you could provide a high-level description/overview of the changes, that would be helpful in reviewing this

[rakshasa]

Issues with the old code:

• want* variables did not have memory barriers when being accessed from the messageHandler.
• firstBlockChan did not report errors.
• GetCurrentTip always resulted in find intersect requests, and was difficult to improve with the old code.
• Channels make it easier to implement chaining of multiple requests, e.g. for GetAvailableBlockRange.

By using channels here we reduce the number of struct member variables and make it follow golang idioms. While using atomic bool would fix the main issue, it doesn't help future improvements in making the chainsync client asynchronous and able to chain requests.

waitingForCurrentTipChan will process all the requests for the current tip until the channel is empty.

want* only processes one request per message reply received from the server. If the message request fails, it is the responsibility of the caller to clear the channel.

GetCurrentTip splits the types of requests into one (waiting*) that just piggybacks on any current incoming messages, while the other (want*) is a one-to-one request/reply.

[agaffney]

Sorry that it took so long to review this PR. These changes look great, and we appreciate these contributions!