metric_readers section name could be shortened to readers

[mx-psi]

TL;DR

The metric_readers section can be shortened to readers which would be shorter while still being readable and concrete enough, and would make the OpenTelemetry Collector telemetry configuration cleaner.

Longer explanation & context

On open-telemetry/opentelemetry-collector/pull/7871 we are using the Configuration WG's meter_provider configuration schema as part of the OpenTelemetry Collector telemetry configuration. In this case, configuring a reader looks like the following:

# collector.yaml sample telemetry configuration
service:
  telemetry:
    metrics:
      metric_readers:
        pull/prometheus:
          # ...

As noted, this matches the example on this repository:

opentelemetry-configuration/kitchen-sink-example.yaml

Lines 64 to 69 in 362b23e

	meter_provider:
	metric_readers:
	# Add a pull-based metric reader.
	pull/prometheus:
	exporter:
	prometheus:

Although I believe in our case it is specially more salient because our top level configuration is named metrics, I still think on the base example on this repository the metric_ prefix for the metric_readers subsection is redundant: a meter provider will presumably never have any other kind of reader.

[codeboten]

The name metric_reader was chosen as a way to remain consistent w/ the definition in the specification. After reviewing some of the other fields in the current configuration, it is clear that there are currently inconsistencies already. For example exporter under the pull/prometheus/ should be named metric_exporter. Although we could go the route of prefixing everything here, this would make the configuration quite repetitive.

After a discussion in the working group call this morning, the proposal is to drop the following prefixes under each provider:

• For meter provider: metric_
• For tracer provider: span_
• For logger provider: logrecord_

This would allow us to create a consistent rule to make expectations clear for users. WDYT @mx-psi?

[mx-psi]

@codeboten That makes sense to me 👍 In all cases in the current schema I believe everything is still readable while being shorter after dropping those prefixes