Remove options, stick with builder

[reyang]

Related to #1858 and #1833.

Changes

I would propose that we only use builder as the configuration, instead of having both builder and options pattern.
This could also help us to have a consistent model when we convert raw metrics to logs, activities to sampled metrics, activity events to logs, and logs to activity events - as discussed here.

Couple benefits:

• Smaller API surface
• Avoid the confusion of having two ways of doing things
• Builder pattern allows people enable/disable things, rather than configuration - once set you're done and there is no way for the others to disable it in their code.

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Design discussion issue Automatically detect exceptions and set Activity status #1853
• Changes in public API reviewed

[codecov]

Codecov Report

Merging #1875 (13b0bfd) into main (cb066cb) will decrease coverage by 0.55%.
The diff coverage is 78.63%.

@@            Coverage Diff             @@
##             main    #1875      +/-   ##
==========================================
- Coverage   83.77%   83.22%   -0.56%     
==========================================
  Files         187      188       +1     
  Lines        5967     6129     +162     
==========================================
+ Hits         4999     5101     +102     
- Misses        968     1028      +60     

Impacted Files	Coverage Δ
src/OpenTelemetry/Sdk.cs	100.00% <ø> (ø)
src/OpenTelemetry/Logs/OpenTelemetryLogger.cs	26.82% <20.54%> (-44.60%)	⬇️
src/OpenTelemetry/Logs/LogRecord.cs	82.50% <77.77%> (-5.00%)	⬇️
.../OpenTelemetry/Logs/OpenTelemetryLoggerProvider.cs	77.55% <88.23%> (+7.09%)	⬆️
src/OpenTelemetry/Trace/ExceptionProcessor.cs	90.90% <90.90%> (ø)
...rc/OpenTelemetry/Trace/TracerProviderBuilderSdk.cs	89.83% <91.66%> (-0.92%)	⬇️
src/OpenTelemetry/Trace/TracerProviderSdk.cs	95.16% <98.64%> (+4.38%)	⬆️
...metryProtocol/Implementation/ActivityExtensions.cs	86.89% <100.00%> (+0.05%)	⬆️
...ry.Instrumentation.AspNet/AspNetInstrumentation.cs	100.00% <100.00%> (ø)
...umentation.AspNet/Implementation/HttpInListener.cs	89.10% <100.00%> (ø)
... and 24 more

[ejsmith]

I really don't get the motivation for this. This is a pretty standard pattern. Options is the root thing that can just be new'd up and you can configure the options yourself. But a builder wrapper around that to provide a fluent API for setting up your configuration. It's the exact same pattern that appears about 1000 times all over the .NET generic host and ASP.NET and many many other systems.

[alexvaluyskiy]

OpenTelemetry docs says that SDK should not have any breaking changes. At least for one year. I think, this PR changes the way to configure of OpenTelemetry, and break the compatibility.

[cijothomas]

OpenTelemetry docs says that SDK should not have any breaking changes. At least for one year. I think, this PR changes the way to configure of OpenTelemetry, and break the compatibility.

There is no breaking change. This PR is reverting an option which was introduced last week (and never released, as indicated by changes to .publicapi.unshipped.txt).

[CodeBlanch]

@reyang Just curious, what's the use case you were thinking of for adding with enabled = false?

[reyang]

The spec SIG is working on "Convenience" API. I imagine at certain point we might have customers extending the API and provide something like:

Sdk.CreateTracerProviderBuilder()
    .EnableFamilyPack() // which includes SetErrorStatusOnException(true)
    .SetErrorStatusOnException(false)