Verify otel-specification requirements

[Kielek]

Go through otel-specification.
Verify if we meet all required parts. Create tasks to implement missing functionalities if needed.

[Kielek]

Raw notes. Issues created, mostly on SDK side. It will be good to review on SIG meeting if any of them is a blocker on our side.
Notes based on the otel-spec folder/file structure

Based on opentelemetry specification pre - v 1.18

- experimental
  - metrics
    - config-service.md - Not supported
  - trace
    - zpages.md - Not supported
- internal - not really specification
- schemas - changes descritpion between versions
- schemas_conventions - yaml based schema, coverted to md under specification
- specification
  - baggage
    - looks good on SDK, optional Metadata paramter not found - issue reported https://github.com/open-telemetry/opentelemetry-dotnet/issues/4152
  - common
    - attribute-naming.md - generak requierments - nothing to check on Autoinstrumentation level
	- attribute-requirement-level.md - nothing to check on Autoinstrumentation level, we could go through all instrumentation specification for detailed evaluation, done already by Dawid some time ago - nothing to do more
	- attribute-type-mapping.md - nothing to check on Autoinstrumentation level
	- mapping-to-non-otlp.md - lacks on the SDK side, for sure for otel.dropped_attributes_count, otel.dropped_events_count, otel.dropped_links_count -https://github.com/open-telemetry/opentelemetry-dotnet/issues/4160
	- README.md - nothing to check on Autoinstrumentation level
  - compatibility
      - opencensus.md - not supported cass, nothing to check on Autoinstrumentation level
	  - opentracing.md -we have opentracing shim support
	  - prometheus_and_openmetrics.md - (converting metrvis between different formats) nothing to check on Autoinstrumentation level
	  - README.md - empty
  - context
      - api-propagators.md - tracecontext, baggage, b3, b3multi seems sufficient, check with OTEL_PROPAGATORS note
	  - README.md - used propagatos seems to be ehough, check previous line
  - logs
      - whole signal is marked as experimental. We have some base support for it, should be enough for 1.0 - consider to disable by default on our side/mark as experinemtan and subject to change https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/2173
  - metrics
      - sdk_exporters - otlp, prometheus and console supported, (promethesu and console only for dev purposes)
	    - otlp - OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE and OTEL_EXPORTER_OTLP_METRICS_DEFAULT_HISTOGRAM_AGGREGATION not supported - https://github.com/open-telemetry/opentelemetry-dotnet/issues/3756 (https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/1405)  and https://github.com/open-telemetry/opentelemetry-dotnet/issues/4153
		- semantic_convention - checked some tiem ago by Dawid, should be sufficient for 1.0
	  - the biggest drawback are exemplars - targeted for 1.5.0
  - protocol
      - design-goals.md - nothing nothing to check on Autoinstrumentation level
      - exporter.md `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` `OTEL_EXPORTER_OTLP_METRICS_ENDPOINT` `OTEL_EXPORTER_OTLP_LOGS_ENDPOINT`, `OTEL_EXPORTER_OTLP_INSECURE` ` ` `OTEL_EXPORTER_OTLP_METRICS_INSECURE` `OTEL_EXPORTER_OTLP_LOGS_INSECURE` `OTEL_EXPORTER_OTLP_SPAN_INSECURE` `OTEL_EXPORTER_OTLP_METRIC_INSECURE`, `OTEL_EXPORTER_OTLP_CERTIFICATE` `OTEL_EXPORTER_OTLP_TRACES_CERTIFICATE` `OTEL_EXPORTER_OTLP_METRICS_CERTIFICATE` `OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE`, `OTEL_EXPORTER_OTLP_CLIENT_KEY` `OTEL_EXPORTER_OTLP_TRACES_CLIENT_KEY` `OTEL_EXPORTER_OTLP_METRICS_CLIENT_KEY` `OTEL_EXPORTER_OTLP_LOGS_CLIENT_KEY`, `OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE` `OTEL_EXPORTER_OTLP_TRACES_CLIENT_CERTIFICATE` `OTEL_EXPORTER_OTLP_METRICS_CLIENT_CERTIFICATE` `OTEL_EXPORTER_OTLP_LOGS_CLIENT_CERTIFICATE`, OTEL_EXPORTER_OTLP_COMPRESSION, `OTEL_EXPORTER_OTLP_TRACES_TIMEOUT` `OTEL_EXPORTER_OTLP_METRICS_TIMEOUT` `OTEL_EXPORTER_OTLP_LOGS_TIMEOUT`, `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` `OTEL_EXPORTER_OTLP_METRICS_PROTOCOL` `OTEL_EXPORTER_OTLP_LOGS_PROTOCOL` - lack of support on SDK side - https://github.com/open-telemetry/opentelemetry-dotnet/issues/4154
      - file-exporter.md - experimental, not supported
	  - otlp.md - nothing nothing to check on Autoinstrumentation level
	  - READMEmd - nothing nothing to check on Autoinstrumentation level
	  - requirements.md - nothing nothing to check on Autoinstrumentation level
  - resource
      - semantic_convention - contrib issues - all experimentals, not needed for 1.0
	    - only README.md: Serivce and Telemetry SDK attributes handled
		- faas.md - faas.name is marked as requierd (experimental)
		- os.md - os.type is marked as requierd (experimental)
		- process.md At least one of the following sets of attributes is required: `process.executable.name`, `process.executable.path`, `process.command`, `process.command_line`, `process.command_args`
		- webengine.md  `webengine.name` is marked as requierd (experimental)
	  - README.md - empty
	  - sdk.md - current api looks enough, for logs could be better, but we have our own layer for plugins.
  - schemas
      - Experimental, I do not see any support on SDK side for this
  - trace
      - sdk_exporters
	    - jeager.md - will be obsolete, not supporty by us
		- zipkin.md - recommended attribute values looks strange. OTel based does not reflect current specification. - PR with fix already in progress  https://github.com/open-telemetry/opentelemetry-specification/pull/3087/files
	  - semantic_convention - internally checked by Dawid, compliant, part of recommended attributes missing, enough for 1.0.
      - api.md - lack of support for optional parameters for TracerProvider schema_url and attributes
	  - README.md - empty
	  - sdk.md - part fo the SDK, nothing to check on Autoinstrumentation side
	  - tracestate-handling.md - experimental, as part of w3c propagator
	  - tracestate-probability-sampling.md - current sampling support seems be enough
  - document-status.md - status description, nothing to check on Autoinstrumentation level
  - error-handling.md -
    - self diagnostics - I do not think that we have it for SDK,  - recommendation - maybe post 1.0
	- configure default error handler - I do not think that we have it for SDK, looks not typical to .NET- https://github.com/open-telemetry/opentelemetry-dotnet/issues/4159
	                                  - format exception issue on our side- always silently continue  - should be covered by https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/2039
  - library-guidelines.md - to general to review I would say nothing to check on Autoinstrumentation level
  - library-layout.md - internal project struture - we could think about it after GA. It is not the contract with end-users in our case.
  - overview.md - nothing to check on Autoinstrumentation level
  - performance-benchmark.md - more to to on SDK level, we could think later on this
  - performance.md - two important things to discuss
    - "API should not degrade the end-user application as possible. So that it should not block the end-user application nor consume too much memory resource."
	- "Logging could consume much memory by default if the end-user application emits too many logs. This default behavior is intended to preserve logs rather than dropping it. To make resource usage bounded, the end-user should consider reducing logs that are passed to the exporters." - filtering logs https://github.com/open-telemetry/opentelemetry-specification/blob/17013e74685d554d112f92e053e279431a287cb0/specification/performance.md#L1 - next topic to by default disable it - https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/2173
  - project-management.md - nothing to check on Autoinstrumentation level
  - README.md - nothing to check on Autoinstrumentation level
  - sdk-configuration.md - SDK - confiugure programticaly and by other mechanism, nothing to check on Autoinstrumentation level
  - sdk-environment-variables.md
    - boolean - parsing part https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/2089
    - OTEL_SDK_DISABLED (Stable) - not supported on SDK level - check or create on SDK side https://github.com/open-telemetry/opentelemetry-dotnet/issues/4155
	- OTEL_LOG_LEVEL (Stable) - https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/372
	- OTEL_PROPAGATORS (Stable) - jaeger, ottrace, xray are not supported
	- OTEL_TRACES_SAMPLER (Stable) - jaeger_remote and xray are not supported
	- OTEL_LOGRECORD_ATTRIBUTE_VALUE_LENGTH_LIMIT and OTEL_LOGRECORD_ATTRIBUTE_COUNT_LIMIT (both experimental) - https://github.com/open-telemetry/opentelemetry-dotnet/issues/4156
	- OTEL_EXPORTER_ZIPKIN_TIMEOUT (Stable) - not supported by SDK - https://github.com/open-telemetry/opentelemetry-dotnet/issues/4157
	- OTEL_EXPORTER_PROMETHEUS_HOST and  OTEL_EXPORTER_PROMETHEUS_PORT (both Experimental) no suported by SDK, not importatn so much as we are using it only for dev-purposes - https://github.com/open-telemetry/opentelemetry-dotnet/issues/4158
  - telemetry-stability.md - Confirms that https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/2007 is needed
  - vendors.md - vendors description nothing to check on Autoinstrumentation level
  - versioning-and-stability.md - versioning description, nothing to check on Autoinstrumentation level

[Kielek]

SIG notes: Non of the linked issues looks like a blocker for us.
If we have some time we should focus on open-telemetry/opentelemetry-dotnet#4154