feat(mockotlpserver): add http tunnel option

[david-luna]

No description provided.

[trentm]

Nice. Some notes:

• We aren't getting into HTTP CONNECT tunneling here
  (https://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_Tunneling).
  This would require the client (i.e. the OTel exporter) to support
  a proxy setting. See Undici's ProxyAgent docs for an idea on how
  this would be done if the client was using Undici: https://undici.nodejs.org/#/docs/api/ProxyAgent.md
• I think ideally should be using .pipe() to stream the request to
  the target OTLP server. E.g., see:
  https://stackoverflow.com/questions/75514071/how-i-can-reverse-proxy-https-requests-using-nodejs
• The piping of the target's response as well would be good
  to better handle real error cases. I.e. mockotlpserver's documentation
  for --proxy would state that the target OTLP server's response
  will be returned. When not using --proxy the mockotlpserver returns
  a minimal success response, regardless of the request content.
• For mockotlpserver to get the request body (for pretty printing) it could
  probably stick with the .on('data' being used now, or it could change
  to .pipe() to a stream.Writable that buffers, e.g. https://stackoverflow.com/a/19909245
• For auth: my understanding is that a forward proxy like this one (i.e.
  one that is NOT using HTTP CONNECT), should use the Authorization
  header in the client request as the Authorization header in the
  proxied request. (If the proxy itself requires auth, then
  the Proxy-Authorization header would be used.
  https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authorization
  However, mockotlpserver doesn't require auth, so no need for this other
  header.)

[trentm]

Also not sure --proxy is the correct term here. Per https://datatracker.ietf.org/doc/html/rfc7230#section-2.3 this feature is more like a tunnel.

(Using --proxy as the optional name could be confusing. Compare, for example, to curl --proxy ... which is about tell curl to use that proxy to send all its outgoing requests to.)

[david-luna]

@trentm I've changed the option to tunnel as you suggested. I though of adding the option of multiple destinations but for our testing use case one is enough. We could do some follow up PRs to:

• add multiple destinations
• support GRPC

[trentm]

I haven't tried it yet, but this looks great. One nit/suggestion.