[sdk-node, sdk-metrics] support options to `ConsoleMetricExporter` from declarative config

[trentm]

Take this declarative config:

file_format: "1.1"
meter_provider:
  readers:
    - periodic:
        exporter:
          console:
            temporality_preference: delta
            default_histogram_aggregation: base2_exponential_bucket_histogram

Once #6954 is merged, attempting to startNodeSDK() with this declarative config will result in this diag.warn:

Config warning: some specified PushMetricExporter configuration properties were not handled by SDK setup: ["temporality_preference","default_histogram_aggregation"]

This issue is about supporting those temporality_preference and default_histogram_aggregation options.
They could be handled separately, because there are separate issues for each.

default_histogram_aggregation

• First, one needs to add support for meaningfully passing a default_histogram_aggregation value to ConsoleMetricExporter.

  opentelemetry-js/packages/sdk-metrics/src/export/ConsoleMetricExporter.ts

  Lines 13 to 15 in 636e27a

  	interface ConsoleMetricExporterOptions {
  	temporalitySelector?: AggregationTemporalitySelector;
  	}

  It isn't obvious to me how best to do that. For example the OtlpGrpcMetricExporter type in declarative config (https://opentelemetry.io/docs/specs/otel-config/types/#type-otlpgrpcmetricexporter) also takes a default_histogram_aggregation. The OTLPMetricExporter from @opentelemetry/exporter-metrics-otlp-grpc takes a aggregationPreference argument that is built from this default_histogram_aggregation value. (See aggregationSelectorFromConfig from fix(sdk-node)!: fail-fast on MeterProvider creation from config file #6954)
  Is having an aggregationPreference argument to ConsoleMetricExporter reasonable?

• Second, one needs to update the case 'console' in createPushMetricExporterFromConfig() once fix(sdk-node)!: fail-fast on MeterProvider creation from config file #6954 is merged.

temporality_preference

ConsoleMetricExporter currently accepts a temporalitySelector?: AggregationTemporalitySelector; argument.

However, some issues here:

1. This temporalitySelector is not the same type for specifying a temporality_preference config value as is currently accepted by the OTLPMetricExporter classes. They take a temporalityPreference:

opentelemetry-js/experimental/packages/opentelemetry-exporter-metrics-otlp-http/src/OTLPMetricExporterOptions.ts

Lines 12 to 17 in 636e27a

	export interface OTLPMetricExporterOptions extends OTLPExporterConfigBase {
	temporalityPreference?:
	| AggregationTemporalityPreference
	| AggregationTemporality;
	aggregationPreference?: AggregationSelector;
	}

Would it be better to have ConsoleMetricExporter and OTLPMetricExporter accept the same type of option for a "temporality preference"?

2. In addition to that, there is some confusion (and I think a limitation) in the AggregationTemporalitySelector type accepted by ConsoleMetricExporter.

That type is as follows:

export enum AggregationTemporality {
  DELTA,
  CUMULATIVE,
}

export type AggregationTemporalitySelector = (
  instrumentType: InstrumentType
) => AggregationTemporality;

That AggregationTemporality does not support the "low_memory" the value for temporality_preference defined in declarative config:

    "ExporterTemporalityPreference": {
      "type": [
        "string",
        "null"
      ],
      "enum": [
        "cumulative",
        "delta",
        "low_memory"
      ]
    },

Now look at the type used for OTLPMetricExporter's:

export interface OTLPMetricExporterOptions extends OTLPExporterConfigBase {
  temporalityPreference?:
    | AggregationTemporalityPreference
    | AggregationTemporality;
  aggregationPreference?: AggregationSelector;
}

export enum AggregationTemporalityPreference {
  DELTA,
  CUMULATIVE,
  LOWMEMORY,
}

Why does are there both enum AggregationTemporalityPreference and enum AggregationTemporality?
The latter is missing LOWMEMORY.
I haven't looked at the history here.
Do we need a breaking change to sdk-metrics to get to just one type?

[trentm]

Why does are there both enum AggregationTemporalityPreference and enum AggregationTemporality?
The latter is missing LOWMEMORY.

On the OTel JS SIG call today, Marc clarified this for me. The "...Preference" enum is for user specifying a pref. That gets resolved to a temporality setting per instrument type (one of cumulative or delta). So, having the two separate enums can make sense.

There is still open discussion on what the config options to ConsoleMetricExporter should be and where the AggregationTemporalityPreference preference should live. Marc was arguing that sdk-metrics would be a good place to hold the logic / convenience options for specifying the preferences. Currently that lives in the otlp-metrics-exporter package(s)... which can result in duplication of code when the console exporter also needs the equivalent functionality.