fix: remove unuseful patch message from instrumentations

[blumamir]

#2107 removed the diag prints on InstrumentationNodeModuleDefinition and InstrumentationNodeModuleFile, patch and unpatch callbacks, as this message is now hoisted to be emitted consistently from the base class. The scope of this PR was narrow to handle specific types of messages that became redundant, but it was noted that there are other diag prints for patching and unpatching specific function from moduleExports.

This PR is a followup to #2107

• Cleanup diag patch messages for trivial function which created noise and added no real value for troubleshooting to users.
• Document guidelines on using diag channel to emit patch messages, based on the examples I observed in the repo.

[blumamir]

@JamieDanielson @trentm @pichlermarc thanks again for the great feedback and discussion on the previous PR.

Since those changes were intentionally left out of the previous one, I opened a follow-up to apply the issues we talked about in a dedicated PR. I also added a section to the GUIDELINES.md file for future reference to capture the decisions.

Please let me know if this work correctly reflects the discussion in #2107 🙏

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.45%. Comparing base (dfb2dff) to head (8185fbd).
Report is 99 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2161      +/-   ##
==========================================
- Coverage   90.97%   90.45%   -0.53%     
==========================================
  Files         146      147       +1     
  Lines        7492     7571      +79     
  Branches     1502     1589      +87     
==========================================
+ Hits         6816     6848      +32     
- Misses        676      723      +47     

Files	Coverage Δ
...ode/instrumentation-tedious/src/instrumentation.ts	92.30% <ø> (-0.17%)	⬇️
...lemetry-instrumentation-dns/src/instrumentation.ts	94.59% <ø> (+11.05%)	⬆️
...try-instrumentation-fastify/src/instrumentation.ts	95.41% <ø> (-0.07%)	⬇️
...emetry-instrumentation-hapi/src/instrumentation.ts	99.30% <ø> (-0.01%)	⬇️
...emetry-instrumentation-knex/src/instrumentation.ts	98.70% <100.00%> (-0.08%)	⬇️
...metry-instrumentation-mysql/src/instrumentation.ts	92.72% <ø> (-0.46%)	⬇️
...etry-instrumentation-mysql2/src/instrumentation.ts	94.52% <ø> (-0.22%)	⬇️
...metry-instrumentation-redis/src/instrumentation.ts	92.68% <ø> (-0.80%)	⬇️

... and 24 files with indirect coverage changes

[JamieDanielson]

I think this looks great - I especially love the addition to the guidelines explaining where it might be useful to have logging about patches. I left a few nits but nothing blocking from me.

[JamieDanielson]

🤩 Love having this guideline written out here

[JamieDanielson]

Oh, another thought I had that I think will probably be updated in the follow-up PR that replaces inconsistent usages of api.diag.debug and similar that aren't using the instrumentation this to allow for this._diag.debug. When we make that change we should update guidelines for that as well, though it will already be easier to follow suit once these are all more consistent 😄

[blumamir]

certainly, I aim to first remove or hoist unneeded diag messages, and then will transform all remaining diag message to use this._diag and update the GUIDELINES.md 👍

open-telemetry/opentelemetry-js#4663 will also help in hosting many diag prints and remove the repeated code from dozens of places in contrib.

[blumamir]

Thank you @JamieDanielson

Your suggestions are always valuable. addressed all the comments 🙏