[confighttp] ServerConfig support for automatic deadline

[jmacd]

Is your feature request related to a problem? Please describe.
The otlpreceiver supports gRPC and HTTP. For the gRPC protocol, there is an automatic deadline applied by gRPC itself. For the HTTP protocol, no deadline is applied. This makes a confusing story for users of the receiver, who need a ensure their pipelines consistently use timeouts. Although OTel exporters generally arrange a timeout automatically via exporterherlper, this does not universally ensure pipelines have timeouts--think of the processors and connectors and so on which might block and carry context--so receivers should be configurable to ensure there is a definite timeout.

Describe the solution you'd like
Similar to #10452, I would propose a MinTimeout configuration which would apply a minimum timeout if none was otherwise configured. In the case of OTLP/HTTP, there is no standard that says how to communicate a deadline. This would effectively always impose a deadline, when set, until a future where OTLP/HTTP specifies how to communicate a deadline.

Describe alternatives you've considered
It would make sense, I think, for OTLP/HTTP to specify how to communicate a timeout so that receivers could automatically apply a timeout the way gRPC does. In open-telemetry/opentelemetry-collector-contrib#33688, I've proposed to add helper functions for OTel-Arrow to use. It would make sense to standardize these helpers, possibly move them into the collector/contrib tree so they could be used by HTTP (e.g., otlp/http) and gRPC streaming (e.g., otel-arrow) exporters/receivers to convey timeouts.

Additional context
gRPC specifies a syntax for timeouts here: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#requests

Part of open-telemetry/otel-arrow#227

[atoulme]

Is this similar to #5699 ? Please review #10274 and see if that covers well the timeout use case.

[atoulme]

I think this is now fixed with #10275

Closing as complete, please reopen if this is not sufficient.