[opamp] Example in README is confusing

[breedx-splk]

...and it doesn't compile.

The callback is passed to the builder, but one of the callback implementation methods references that same client that is being built. 🐔 vs 🥚 circular dependency.

Not sure what to really do about it, but I think it suggests a gap in the design.

[LikeTheSalad]

I see what you mean about the 🐔 and 🥚 problem.

The design has changed a bit during the contrib implementation PRs, mostly to make it simpler and/or because there were no real use cases that needed some of the functionalities that the original design from the Elastic repo provided. I think a lot of these changes made the design a lot better, but it seems like the ones regarding setting this callback object might have caused some issues, so thanks for the feedback, it comes at a good time too, since we can add as many breaking changes as we need for now 😅

The possible options I see that could avoid the issue you mentioned are the following:

• Reverting back to using start(Callbacks)/stop() methods for the OpampClient object, which allowed passing the callback on an already built client object, avoiding the chicken/egg issue as the client is already created by then. I'll cc @laurit here just in case there might be some reasons why it's better to avoid this option that he'd like to mention, as he's the one who recommended using a simpler closeable approach.
• Providing a setter(Callback) in OpampClient. I'm not a fan of this option because I believe it can cause 3 issues. The first one is about intuitiveness to use the api, as the setter won't be required to get called to set up the client, so I think it's easy to miss. The second one is that a setter is intuitively something you could call multiple times, which I think could enable some other issues. And the third one is that, since there's no start() method, the client starts polling the server as soon as it's built, which can cause racing issues where the callback is set too late to get the first response, which I guess could be worked around by caching responses in memory, though to me it seems to unneccessarily complicate things.
• Reverting back to providing the client object on each of the callback's methods. I couldn't find a reason why keeping it back then, but I guess this might be one. Maybe one downside is that the client object may leak into the callback, and there might be some situations in which that's not desirable? Not sure tbh.

Let me know what you think could work for you, @breedx-splk. I'm also open to other alternatives that I might've missed.

[breedx-splk]

@LikeTheSalad I thought of another approach in #2280, please have a look and let me know what you think. It's different from the approaches you describe above, but I thought worked out to be a reasonable middle-ground. Thanks!