Add plain HTTP transport to OpAMP

[tigrannajaryan]

Resolves #50

Certain applications may not need the OpAMP's capabilities enabled by WebSocket (ability to push configs from server without Agent's polling) and may prefer to implement a simpler HTTP transport. This is likely the case for short-lived Agents such as for example the ones running in AWS lambda. The HTTP transport is likely simpler to implement on the Server (easier to manage connections) and also removes an additional dependency (a WebSocket library) from the client.

We are also considering implementing OpAMP in OpenTelemetry SDKs, which can result in significantly larger number of OpAMP Agents connecting to the Server, so the Server has to handle a larger number of persistent WebSocket connections, which may pose more burden than necessary for use cases where there are no benefits from having a persistent connection (e.g. the above mentioned short-lived use case).

This changes defines a plain HTTP transport for OpAMP. It is a fairly simple modification of the spec to allow it, with AgentToServer/ServerToAgent messages exchanged via HTTP POST Body.

It is also not very complicated to support both WebSocket and plain HTTP on the same Server and if we want to make it seamless from Agent's perspective we can add an indicator of the desired transport in the initial connection attempt made by the Agent, so that the Server knows whether to upgrade to WebSocket or just reply in plain HTTP. The "Content-Type" request header can be such indicator. We can add this in a follow-up PR.

Here is a draft Go OpAMP server implementation for reference: open-telemetry/opamp-go@main...tigrannajaryan:plain-http-transport

[anuraggujral]

In the above PR, it is not clear from the second paragraph that here we are considering OpenTelemetry SDKs as agents, may be very should make it more explicit.

[tigrannajaryan]

@pmm-sumo what do you think about this change?

[pmm-sumo]

@pmm-sumo what do you think about this change?

I think it will be a very useful addition. I think it might be worth running by OpenTelemetry SDK's maintainers, since this is one of the use cases for it