Add CustomMessage capability

[andykellr]

See #49

If we agree on the direction of this, I plan to do the following:

• updates to this opamp-spec PR:
  • add protos to the opamp.proto file
• updates to the opamp-go repo in a separate PR:
  • add OnCustomMessage method to the client Callbacks interfaces
  • add SendCustomMessage to the OpAMPClient
  • add implementation to the client and server
  • add tests for that implementation

[andykellr]

@tigrannajaryan please review and I will update and fill in the rest. Thanks!

[andykellr]

Related to this, should we enforce line-length in .markdownlint.yaml? My editor wraps at 120. I noticed most of the existing lines are between 80-90.

[tigrannajaryan]

Related to this, should we enforce line-length in .markdownlint.yaml? My editor wraps at 120. I noticed most of the existing lines are between 80-90.

Yes, please keep the line wraps similar to the rest of the spec (I think it is at 90).

[andykellr]

I made significant changes to this proposal and have some time to work on the implementation. @tigrannajaryan please have a look.

[jaronoff97]

Had one question, overall I'm a fan of this change. It would be great for the future to support custom messages to allow the protocol to be extended upon more easily. For the operator group, I could imagine the bridge allowing for a message for restarting a workload or even pausing telemetry as in the examples.

[andykellr]

Related to this, should we enforce line-length in .markdownlint.yaml? My editor wraps at 120. I noticed most of the existing lines are between 80-90.

Yes, please keep the line wraps similar to the rest of the spec (I think it is at 90).

I attempted to enforce this with the following change, but it requires many sections to be rewrapped to meet the requirement. I can do this in a separate PR if we believe it should be enforced.

<!-- markdownlint-configure-file
{
  "line-length": {
    "line_length": 90,
    "stern": true
  }
}
-->

[portertech]

Just a thought. Although probably unlikely, a string capability for one server may differ from the functionality on another (e.g. vendor) and a connecting agent may not know any better resulting in unexpected behaviour. Do we care about interoperability? Do the strings need to be distro/vendor specific? Do we need another field?

[andykellr]

The intent is that they would use a reverse FQDN to be vendor specific, e.g. our pause/resume feature might be com.observiq.pause. I used io.opentelemetry in the examples to keep vendor specific names out of the spec.

[andykellr]

I just updated the PR with CustomCapabilities in addition to CustomMessage as discussed above.

[evan-bradley]

Overall this looks good to me, I only have minor comments on wording.

[tigrannajaryan]

LGTM.

Just 2 small nits and we can merge after that.