Unify queueSize metric description and attribute

[puckpuck]

Fixes #4834

Also references #4382 and #5066

The Java SDK, when auto-configured, will emit 2 metrics with the same metric name (queueSize) but a different description. Combined with the very popular Prometheus exporter in the OpenTelemetry Collector, this leads to an error and 1 of the 2 metrics being dropped. The metric is emitted as part of the Batch*Processors for traces and logs.

This PR uses the same description for both metrics and updates an attribute key to be common across both. The Attribute name could be seen as a larger change outside the scope of this PR, and I'm happy to remove it. In my opinion, when I look at how this metric could be used, I see a benefit with using a common name of processorType for the attribute key.

I also understand there may be a larger issue at the specification level to help resolve this, but this issue has existed for well over a year. It can be resolved with this PR while waiting for the specification to be clearer on handling these use cases.

[codecov]

Codecov Report

Patch coverage is 100.00% of modified lines.

Files Changed	Coverage
...metry/sdk/logs/export/BatchLogRecordProcessor.java	100.00%
...telemetry/sdk/trace/export/BatchSpanProcessor.java	100.00%

📢 Thoughts on this report? Let us know!.

[breedx-splk]

LGTM...thanks for the contribution.

[jack-berg]

Yeah this has been a problem for too long. Thanks for the fix.

Opened #5856 to track some remaining issues for these metrics.

[jack-berg]

Thought about this more. Ideally we would get all the problems of #5856 fixed in a single release to minimize churn, but that is dependent on progress in semantic-conventions which doesn't appear to be making quick progress. So we can either:

1. wait an unknown amount of time for semantic-conventions to resolve the issue and limit the churn here, but continue having a bad prometheus experience until then
2. make the simplest possible change to fix the prometheus experience now, with the expectation of churning again when the semantic-conventions issue resolves

Would be partial to option 1 if there was an end in sight for the semantic-conventions repo, but its not reasonable to have broken prometheus experience without a clear path and timetable to fix.