[Experiment] repro: comet query client

[bryanchriswhite]

Summary

Human Summary

This branch is an attempt to replace our "custom" comet RPC client for event subscriptions (using the gorilla websocket package). As noted above the QueryClient interface definition in pkg/client/interface.go, such a thing seems to exist in the cometbft repo; however, my attempts at getting it to work, for our use case at least have been unsuccessful. I think there's likely something basic that I'm misunderstanding or an assumption that I don't realize I'm making. 🤔

AI Summary

Summary generated by Reviewpad on 26 Oct 23 18:51 UTC

This pull request implements a new HTTP RPC client for the comet_query package. It introduces a new cometQueryClient struct that handles querying events from a remote CometBFT node. The client can subscribe to specific events and receive event data in the form of bytes. The implementation includes functions for starting the client, subscribing to events, and producing events. Additionally, a test is added to verify the functionality of the EventsBytes method.

Issue

Relates to:

• [Miner] feat: add events query client #64

Improve maintainability (owning less code).

Type of change

Select one or more:

• New feature, functionality or library
• Bug fix
• Code health or cleanup
• Documentation
• Other (specify): experiment / reproduction

Testing

• Run all unit tests: make go_test
• Verify Localnet manually: See the instructions [here](TODO: add link to instructions)

Sanity Checklist

• I have tested my changes using the available tooling
• I have performed a self-review of my own code
• I have commented my code, updated documentation and left TODOs throughout the codebase

[Olshansk]

@bryanchriswhite Can you link to this PR (#74) in the comments next to our implementation?

[Olshansk]

@bryanchriswhite You asked me to TAL at this in this comment but it's not something I've ever used or looked into so I honestly don't think there's any value I can provide.

Was there something specific you wanted me to look into or just be aware of this PR?

[bryanchriswhite]

That comment was a follow-up to #64 (comment), where you had asked about "why don't we use their client?" and #64 (comment) with a similar question about if we switch to theirs do we still need our interfaces. The main reason I wanted you to see this was to add clarity to my responses there.

@bryanchriswhite Can you link to this PR (#74) in the comments next to our implementation?

There already is a code comment next to the interface, which is why I was apologizing in that github comment. The base branch moved since opening #74 and made the PR unreadable. The code comment is a couple lines below where you had placed the github comment, it reads:

// NOTE: a branch which attempts this is available at:
// https://github.com/pokt-network/poktroll/pull/74

Do you have a strong opinion about having it closer to the implementation instead?

[Olshansk]

@bryanchriswhite Thoughts on closing this PR? We have it available as a reference (be it closed or not) moving forward.

[bryanchriswhite]

@Olshansk no preference from me; whatever's most convenient for project management.