Fix MongoDB instrumentation for 2.29.0+

[Kielek]

Why

Fixes #3667 (comment)

What

Fixes loading MongoDB related assemblies.

MongoDB.Driver.Core 2.28.0+ are signed. What is more MongoDB does not follow recommendation about Assembly Versioning and Assembly Version is Equal to Library version (2.28.0.0 and 2.29.0.0).

MongoDB.Driver.Core.Extensions.DiagnosticSources references MongoDB.Driver.Core v2.28.0.
When the test application is using MongoDB.Driver.Core v2.28.0. It leads to following error:

[2024-09-26T06:23:46.2073304Z] [Debug] EventSource=OpenTelemetry-AutoInstrumentation-Loader, Message=Requester [<null>] requested [MongoDB.Driver.Core, Version=2.28.0.0, Culture=neutral, PublicKeyToken=94992a530f44e321] 
[2024-09-26T06:23:46.2920125Z] [Debug] EventSource=OpenTelemetry-AutoInstrumentation-Loader, Message=Requester [<null>] requested [MongoDB.Driver.Core, Version=2.28.0.0, Culture=neutral, PublicKeyToken=94992a530f44e321] 
[2024-09-26T06:23:46.3390112Z] [Error] Could not load file or assembly 'MongoDB.Driver.Core, Version=2.28.0.0, Culture=neutral, PublicKeyToken=94992a530f44e321' or one of its dependencies. The system cannot find the file specified.
Exception: Could not load file or assembly 'MongoDB.Driver.Core, Version=2.28.0.0, Culture=neutral, PublicKeyToken=94992a530f44e321' or one of its dependencies. The system cannot find the file specified.
System.IO.FileNotFoundException: Could not load file or assembly 'MongoDB.Driver.Core, Version=2.28.0.0, Culture=neutral, PublicKeyToken=94992a530f44e321' or one of its dependencies. The system cannot find the file specified.
File name: 'MongoDB.Driver.Core, Version=2.28.0.0, Culture=neutral, PublicKeyToken=94992a530f44e321'
   at System.Signature.GetSignature(Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInternal fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType)
   at System.Reflection.RuntimeMethodInfo.InvokeArgumentsCheck(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
   at OpenTelemetry.AutoInstrumentation.Instrumentations.MongoDB.MongoClientIntegration.GetInstrumentationOptions()
   at OpenTelemetry.AutoInstrumentation.Instrumentations.MongoDB.MongoClientIntegration.GetClusterConfiguratorExpression()
   at OpenTelemetry.AutoInstrumentation.Instrumentations.MongoDB.MongoClientIntegration.OnMethodBegin[TTarget,TMongoClientSettings](TTarget instance, TMongoClientSettings settings)
   at OpenTelemetry.AutoInstrumentation.CallTarget.Handlers.BeginMethodHandler`3.Invoke(TTarget instance, TArg1& arg1)
   at MongoDB.Driver.MongoClient..ctor(MongoClientSettings settings)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Workaround - ignore versioning check and load assembly manually by the name (from the application context).

Alternatives

1. Fully drop references to MongoDB.Driver.Core.Extensions.DiagnosticSources and implement instrumentation as a bytecode (we need it already partially to enable instrumentation). It can be done before release or as the follow up.

2. Revert changes from: MongoDB.Driver.Core - support only 2.28.0+ #3604 and GraphQL support for 8.0+ #3615. It might be not the best option if we check download statistics from the last 6 weeks.

3. Implement instrumentation on the MongoDB side, but it not short term solution.

Tests

Tested locally, as tests for MongoDB on .NET Framework are not executed in the pipeline.

Checklist

• [ ] CHANGELOG.md is updated.
• [ ] Documentation is updated.
• New features are covered by tests - as a part of release process.

[Kielek]

@nrcventura, @zacharycmontoya, @rajkumar-rangaraj, @pjanotti

What is your opinion? Do you see any better options?

[nrcventura]

I think that this proposed workaround makes sense in the short and medium term. I do not think we should use alternatives 1 and 2. In the long term it would be good to pursue alternative 3.

[nrcventura]

If the newer versions of the library break backwards compatibility, we may need to consider a different approach, or potentially dropping support for certain versions.

[pjanotti]

@Kielek I think the workaround is acceptable.

[rajkumar-rangaraj]

I agree with @pjanotti, this is an acceptable workaround.

[Kielek]

Thank you guys. Merging and moving forward with release.