Add the otelarrow receiver scaffold

[jmacd]

Description: Introduces scaffolding for the new otelarrow receiver.

Link to tracking Issue: #26491

Testing: No new tests, since this is just scaffold. Tests will arrive with the implementation.

Documentation: This README is copied (w/ some URLs updated) from the otel-arrow repository, which housed the component under development. Note this component is already functional, since the scaffold refers to the other repo's components (i.e., its Config and NewFactory).

[jmacd]

Sorry, I realize you'll want this scaffold to use the fields generated from metadata.yaml. I'll re-open.

[jmacd]

I replaced the use of the Config type alias and use of a NewFactory delegate, so now this PR includes the real Config and NewFactory. The config tests have been restored (with testdata, much of this of course stems from the core OTLP receiver component. Half of the factory test has been preserved here, changed to reflect the currently unimplemented status.

[codeboten]

Thanks for breaking this PR up. See comments inline

[codeboten]

Does this need a separate section for configuration? If the only setting is a memory limit, any reason not to include it at the top level?

[jmacd]

Relates to open-telemetry/otel-arrow#43. This code is designed to drop-in where an OTLP receiver once stood, so leaving the Arrow settings in a separate section for future compatibility (was the idea).

[codeboten]

Is http only not a valid configuration for this receiver? if it is, then i would remove this comment and re-enable the check below

[jmacd]

HTTP only means you've disabled OTel Arrow and you're identical to an OTLP receiver. I'm not sure why the user would want this. (Again, open-telemetry/otel-arrow#43 comes up.)

README states:

This receiver listens on the standard OTLP/gRPC port 4317 and serves standard OTLP over gRPC out of the box.

and later

To enable optional OTLP/HTTP support, the HTTP protocol must be explicitly listed. It will use port 4318 by default. The OTel Arrow protocol is not currently supported over HTTP.

if we added OTel Arrow support for HTTP streams, possibly, then it would make sense to apply the change you described, but I think we should separate the two transports into separate components.

[jmacd]

I have updated the README to declare this a multi-protocol receiver the way OTLP is a multi-protocol receiver.

This is a multi-protocol telemetry receiver.  Receives telemetry data
using the standard forms of [OTLP (gRPC, HTTP/proto, HTTP/json)](
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md)
and [OTel-Arrow](https://github.com/open-telemetry/otel-arrow) (gRPC).

[jmacd]

See the design of this multi-protocol feature: https://github.com/open-telemetry/oteps/blob/main/text/0156-columnar-encoding.md#protocol-extension-and-fallback-mechanism

[jmacd]

I will re-open this PR when we have a strategy to avoid duplication of the core OTLP exporter/receiver code.