Move Metrics API behind internal package

[aabmass]

Description

Moves the Metrics API behind an internal package opentelemetry._metrics._internal. This will remain with the underscore once we make a stable release of metrics i.e. opentelemetry.metrics._internal. Finally, all of the public API is expose in opentelemetry._metrics package __init__.py file. This clearly shows what the public is.

Updated tests and documentation to build with these changes.

Fixes #2622

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Tests passing, docs look good

Does This PR Require a Contrib Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[aabmass]

I separated the move of opentelemetry/_metrics/__init__.py into a separate commit so you can review the commits separately it will make your life easier 2c1cb20

[srikanthccv]

LGTM

[ocelotl]

Looks good, I have only one comment, this approach puts all public metric symbols in opentelemetry._metrics, instead of separating them into modules like opentelemetry._metrics.instrument, opentelemetry._metrics.point and so on which is more consistent with what we currently have in tracing.

@lzchen WDYT?

[aabmass]

opentelemetry._metrics.instrument, opentelemetry._metrics.point and so on which is more consistent with what we currently have in tracing.

I took a look at tracing API, we have most stuff directly in opentelemetry.trace like Span, Link, etc:

opentelemetry-python/opentelemetry-api/src/opentelemetry/trace/__init__.py

Lines 588 to 614 in 7647a11

	__all__ = [
	"DEFAULT_TRACE_OPTIONS",
	"DEFAULT_TRACE_STATE",
	"INVALID_SPAN",
	"INVALID_SPAN_CONTEXT",
	"INVALID_SPAN_ID",
	"INVALID_TRACE_ID",
	"NonRecordingSpan",
	"Link",
	"Span",
	"SpanContext",
	"SpanKind",
	"TraceFlags",
	"TraceState",
	"TracerProvider",
	"Tracer",
	"format_span_id",
	"format_trace_id",
	"get_current_span",
	"get_tracer",
	"get_tracer_provider",
	"set_tracer_provider",
	"set_span_in_context",
	"use_span",
	"Status",
	"StatusCode",
	]

Even some stuff from opentelemetry.trace.propagation subpackage, like get_current_span() is re-exposed in opentelemetry.trace package.

I think it's reasonable to separate them out more for the SDK e.g. we could have an opentelemetry.sdk.metrics.export package like in tracing. Up to you @ocelotl as you're working on that PR. Wdyt?

[ocelotl]

opentelemetry._metrics.instrument, opentelemetry._metrics.point and so on which is more consistent with what we currently have in tracing.

I took a look at tracing API, we have most stuff directly in opentelemetry.trace like Span, Link, etc:

opentelemetry-python/opentelemetry-api/src/opentelemetry/trace/__init__.py

Lines 588 to 614 in 7647a11

	__all__ = [
	"DEFAULT_TRACE_OPTIONS",
	"DEFAULT_TRACE_STATE",
	"INVALID_SPAN",
	"INVALID_SPAN_CONTEXT",
	"INVALID_SPAN_ID",
	"INVALID_TRACE_ID",
	"NonRecordingSpan",
	"Link",
	"Span",
	"SpanContext",
	"SpanKind",
	"TraceFlags",
	"TraceState",
	"TracerProvider",
	"Tracer",
	"format_span_id",
	"format_trace_id",
	"get_current_span",
	"get_tracer",
	"get_tracer_provider",
	"set_tracer_provider",
	"set_span_in_context",
	"use_span",
	"Status",
	"StatusCode",
	]

Even some stuff from opentelemetry.trace.propagation subpackage, like get_current_span() is re-exposed in opentelemetry.trace package.

I think it's reasonable to separate them out more for the SDK e.g. we could have an opentelemetry.sdk.metrics.export package like in tracing. Up to you @ocelotl as you're working on that PR. Wdyt?

All right, if in tracing we have everything in the base module, then this approach is consistent. I can work on the corresponding PR for the SDK and have some separation there, approving. 👍