[ASP.NET Core] Remove suppression for metrics generated from prometheus

[vishweshbankwar]

Fixes #
Design discussion issue #

Changes

Remove the special handling of metrics generated as a result of metrics pull from Prometheus endpoint. Any filtering (if at all) should be handled by generic filtering mechanism (if one is available in future).

Please provide a brief description of the changes here.

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 #5044 (64c056c) into main (c062e12) will increase coverage by 0.24%.
Report is 1 commits behind head on main.
The diff coverage is n/a.

❗ Current head 64c056c differs from pull request most recent head c3d9e37. Consider uploading reports for the commit c3d9e37 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5044      +/-   ##
==========================================
+ Coverage   83.34%   83.58%   +0.24%     
==========================================
  Files         296      296              
  Lines       12475    12473       -2     
==========================================
+ Hits        10397    10426      +29     
+ Misses       2078     2047      -31     

Flag	Coverage Δ
unittests	83.58% <ø> (+0.24%)	⬆️

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

Files	Coverage Δ
...AspNetCore/Implementation/HttpInMetricsListener.cs	89.55% <ø> (+1.14%)	⬆️

... and 5 files with indirect coverage changes

[cijothomas]

Probably nit picking, but the wording "may affect" may not be clear as to what is the effect? The effect of this PR is - metrics now include measurements from prometheus scrape requests. So one possible effect is - users see more count and their avge, etc might be affected. Eg: the service's latency is one-digit-ms only, but prometheus scrapes take seconds.. Now, by including prometheus scrapes to the latency metric, it may give false impression that the service slowed! It could be immaterial, if prom scrapes are a minute fraction (quite likely.)

Not a blocker for the PR!

[vishweshbankwar]

I reworded first line a bit more. The point about latency is valid but I don't think it falls under the instrumentation library's scope (library simply reports metrics). I think it was a bug that we were filtering measurements and not giving the full picture.