Enable clients to set flags

[tpaschalis]

Updates #198

This PR adds a new method to the OpAMPClient that allows clients to set their own flags (such as RequestInstanceUid).

This new method deviates a little bit from other ones as it just sets a uint64 instead of a pointer struct field, and doesn't use the same errors and nil checks.

Thank you in advance for taking and look, and please let me know if I'm missing anything! 🙌

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.32%. Comparing base (c64c461) to head (1f74dfd).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #286      +/-   ##
==========================================
+ Coverage   75.96%   76.32%   +0.35%     
==========================================
  Files          25       25              
  Lines        1656     1681      +25     
==========================================
+ Hits         1258     1283      +25     
  Misses        291      291              
  Partials      107      107              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tpaschalis]

cc @srikanthccv I followed your hint over at #198, let me know if I'm missing anything 🙌

[tigrannajaryan]

I think this is missing a couple additional things:

1. Use the Flags from ClientSyncedState in PrepareFirstMessage. This will allow calling SetFlags() before Start() too, which I imagine is useful so that we ask for a new instance id immediately, not after the first request is sent.

2. Also use the Flags from ClientSyncedState when the server asks ServerToAgentFlags_ServerToAgentFlags_ReportFullState here. This is important since the agent may reconnect to a different server instance after the first sending attempt is done but reply carrying the new instance id was not received.

3. Once 1 and 2 are added we need to reset the RequestInstanceUid flag after we receive new_instance_uid from the Server, otherwise we will keep asking for new ids every time. Perhaps do it in rcvAgentIdentification after SetInstanceUid returns success.

I may be missing some more things. This needs a bit more thought and additional test cases that demonstrate the real use cases and behavior in presence of failures.

[tpaschalis]

Thanks for the feedback @tigrannajaryan

I focused only on the client-side implementation but I realize it's a more interconnected change. I'll try to set up an end-to-end test to have at hand and figure out the entire lifecycle of the IDs.

[tpaschalis]

Hey there @tigrannajaryan @srikanthccv 👋 Hope your week is going well!

I've pushed a couple of commits; bd001cf that handles the cases Tigran mentioned on your last message and ca66f1d that adds a test for how messages containing valid/invalid AgentIdentification fields interact with the state of the flag we're tracking.

Let me know how this looks, and if you have any concerns, or ideas. I'm still trying to understand all the moving pieces, so if I'm missing anything please let me know!

[tigrannajaryan]

LGTM. Just one comment left, would be great to add one more test and we can merge.

[tigrannajaryan]

Thank you @tpaschalis