feat: add confighttp configuration with TLS support

[rogercoll]

Fixes: #595

Breaking change in all configurations, from:

apmconfig:
  opamp:
    server:
       endpoint: "http://..."

The new configuration uses a similar approach as the OTLP receiver, where multiple protocols can run simultaneously. Having in mind that Websockets protocol is supported by OpAMP and might be implemented in the future:

apmconfig:
  opamp:
    protocols:
      http:
        endpoint: "http://..."

In addition, the confighttp configuration is used to create the server, thus leveraging all its features (TLS, authentication, CORS, timeout, etc).

[rogercoll]

Now that we are introducing configuration breaking changes (and before adding it to EDOT), I would like to rename the agent_config section as well. I think it should be something more related to the actual behavior; fetching the corresponding remote configurations. Maybe fetcher or remote_config might be more appropriate, any thoughts?

[trentm]

I would like to rename the agent_config section as well.

(Take my feedback with a grain of salt. I have almost no experience with naming OTel Collector-y things.)

Do these config settings need to be namespaced under agent_config or fetcher at all? If this fetching is a fundamental function of this extension, then could it be somethign like:

extensions:
  apmconfig:
    cache_duration: 10s
    elasticsearch:
      endpoint: http://localhost:9200
      auth:
        authenticator: bearertokenauth
    opamp:
      server:
        endpoint: "localhost:4320"

?

---

On the subject of naming: Is there a reason this extension is named apmconfig and not elasticapmconfig? I gather it doesn't really matter, because the component isn't going to be upstreamed every, I would imagine.

[rogercoll]

Do these config settings need to be namespaced under agent_config or fetcher at all?

It's not strictly necessary, but in my opinion, it provides a useful way to distinguish the two core responsibilities of the extension:

• Fetcher: from when to retrieve the remote configuration
• Server: how to communicate with agents

Is there a reason this extension is named apmconfig and not elasticapmconfig? I gather it doesn't really matter, because the component isn't going to be upstreamed every, I would imagine.

I actually believe it could be a candidate for upstreaming. The OpAMP server is designed to be agnostic with respect to the remote configuration fetcher/provider. It relies on a client interface that can be implemented by various fetchers—Elasticsearch being one example (see the Otel parameters here: https://github.com/elastic/opentelemetry-collector-components/blob/main/extension/apmconfigextension/apmconfig/client.go#L39) Indeed, since agent_config is a map, it could be extended to support other providers or fetchers in the future:

extensions:
  apmconfig:
    agent_config:
      kibana:
        endpoint: http://localhost:9200

Or another vendor:

extensions:
  apmconfig:
    agent_config:
      other_vendor:
        url: http://localhost:9200

[ChrsMark]

LGTM