BatchSpanProcessor, BatchLogRecordProcessor metrics don't follow semantic convention naming guidelines

[jack-berg]

The semantic conventions say things like:

• metric names and attributes exist in a single universe
• common attributes should be consistently named

We also generally recommend (though I can't find any explicit text to this) that measurements are recorded with a consistent set of attribute keys for the same instrument. This assists with prometheus/openmetrics compatibility which says:

Metrics are defined by a unique LabelSet within a MetricFamily. Metrics MUST contain a list of one or more MetricPoints. Metrics with the same name for a given MetricFamily SHOULD have the same set of label names in their LabelSet.

We violate this advice in the metrics produced for BatchSpanProcessor and BatchLogRecordProcessor:

• Both produce a metric named queueSize
  • queueSize isn't namespaced
  • queueSize includes attributes logRecordProcessorType for BatchLogRecordProcessor, and spanProcessorType for BatchSpanProcessor. These attributes are inconsistent, and do not have namespaces.
  • queueSize has a different description in BatchSpanProcessor than in BatchLogRecordProcessor
• BatchLogRecordProcessor emits processedLogs
  • processedLogs isn't namespaced
  • processedLogs includes attributes logRecordProcessorType, and dropped. Neither is namespaced.
• BatchSpanProcessor emits processedSpans
  • processedSpans isn't namespaced
  • processedSpans includes attributes spanProcessorType, and dropped. Neither is namespaced.

This leads to issues like #4834. The PR #5836 partially fixes these issues by renaming logRecordProcessorType / spanProcessorType to processorType. But we should go further and fix the remaining issues.

Ideally we would fix everything at once to avoid churn.

[jack-berg]

Related to semantic-conventions#83 which is trying to define language agnostic conventions for these.

[jack-berg]

#7895 solves this for spans.

[jack-berg]

#7931 solves this for logs.