GHSA-w2jh-77fq-7gp8

### Summary

When receiving responses from the OpAMP server over HTTP, the OpAMP client allocates an unbounded buffer to read all bytes from the server, with no upper-bound on the number of bytes consumed.

This could cause memory exhaustion in the consuming application if the configured OpAMP server is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned in the response.

### Details

[#2926](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/2926) introduced the initial HTTP transport components which uses `ReadAsByteArrayAsync` to copy the `HttpResponseMessage.Content` into a byte array. This code path allows an unbounded read of the entire HTTP response message.

### Impact

If an application using the OpAMP client is configured to use an OpAMP server that is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned in the response, the application could have its memory exhausted and create a denial-of-service condition.

### Mitigation

The application's configured OpAMP server needs to behave maliciously. If the OpAMP server is a well-behaved implementation, response bodies should not be excessively large.

### Workarounds

None known.

### Remediation

[#4116](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116) updates the OpAMP client HTTP transport to limit the maximum size of responses to 128KB.

### Resources

- [#2926](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/2926) - [#4116](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116) - [CWE-789](https://cwe.mitre.org/data/definitions/789.html)