[ASP.NET Core] Remove grpc server instrumentation

[vishweshbankwar]

Fixes #
Design discussion issue #

Changes

See issue open-telemetry/opentelemetry-dotnet-contrib#1726

Merge requirement checklist

• CONTRIBUTING guidelines followed (nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

Merging #5097 (3111a2c) into main (4f73d2b) will decrease coverage by 0.16%.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    open-telemetry/opentelemetry-dotnet#5097      +/-   ##
==========================================
- Coverage   83.02%   82.87%   -0.16%     
==========================================
  Files         296      296              
  Lines       12315    12312       -3     
==========================================
- Hits        10225    10203      -22     
- Misses       2090     2109      +19     

Flag	Coverage Δ
unittests	82.87% <ø> (-0.16%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...ion.AspNetCore/AspNetCoreInstrumentationOptions.cs	100.00% <ø> (ø)
...tation.AspNetCore/Implementation/HttpInListener.cs	75.18% <ø> (-13.71%)	⬇️

... and 5 files with indirect coverage changes

[utpilla]

Approved with suggestions.

[alanwest]

Why the decision to comment the functionality out when we could use the EXPOSE_EXPERIMENTAL_FEATURES directive. Seems this causes more toil for us to maintain and for users who may want to use the latest instrumentation.

[vishweshbankwar]

The idea is to have all the breaking changes introduced in rc version itself so that users are aware of what is coming in stable release. After the stable release, we can re-introduce this as experimental.

[utpilla]

We could do that but I think it might be okay to comment this functionality out for the next rc which is supposed to mimic the stable behavior. We could see if people complain about this in the rc and decide to mark it experimental then? Otherwise, we would introduce in the first alpha after the stable release.

[alanwest]

I guess what I'm hearing is that we want to treat rc releases a bit differently than other pre-release monikers like alpha, beta, etc. I'd be fine if we set a precedent that EXPOSE_EXPERIMENTAL_FEATURES is only set for non-rc prereleases. I'm mainly looking for ways we can avoid the commenting/uncommenting toil we've had in the past.

I don't feel strongly that this is performed right now, so if you'd prefer to take the shortcut and comment it out for now then I'm ok with that. Though, I do want to see this reintroduced as soon as possible. I don't need to wait for customers to complain. I know of customers that use this instrumentation. Also, the cartservice from the opentelemetry-demo project is a gRPC service and depends on this instrumentation.

[utpilla]

I guess what I'm hearing is that we want to treat rc releases a bit differently than other pre-release monikers like alpha, beta, etc.

We want to treat this particular rc that we would be releasing next differently. As this is the first time this library would have a stable release so that's why this rc is special than let's say an rc that would happen after we have had a stable release.

Though, I do want to see this reintroduced as soon as possible. I don't need to wait for customers to complain. I know of customers that use this instrumentation.

We would have to tell them that these conventions are not stabilized yet. Ideally (meaning taking the shortcut route), we would add it right after the first stable which should happen in ~2-3 weeks from now.

[alanwest]

we would add it right after the first stable which should happen in ~2-3 weeks from now

ok