GenevaExporter uses Expression.Lambda from System.Linq.Expressions - AOT size and performance concerns

[eerhardt]

When using the GenevaExporter in a native AOT application, it is bringing in System.Linq.Expressions, which adds size to the app, but also any Linq.Expressions are interpreted at runtime (since IL can't be generated).

See the following:

          @eerhardt GenevaExporter also uses `Expression.Lambda` from [System.Linq.Expressions](https://learn.microsoft.com/en-us/dotnet/api/system.linq.expressions?view=net-8.0). Did we not have a Trim/AOT issue when using that?

opentelemetry-dotnet-contrib/src/OpenTelemetry.Exporter.Geneva/Internal/ReentrantExportProcessor.cs

Lines 18 to 25 in ab7bdab

	static ReentrantExportProcessor()
	{
	var flags = BindingFlags.Instance | BindingFlags.NonPublic;
	var ctor = typeof(Batch<T>).GetConstructor(flags, null, new Type[] { typeof(T) }, null);
	var value = Expression.Parameter(typeof(T), null);
	var lambda = Expression.Lambda<Func<T, Batch<T>>>(Expression.New(ctor, value), value);
	CreateBatch = lambda.Compile();
	}

Originally posted by @utpilla in #1666 (comment)

We should decide how to fix this. Options I see are:

1. Make Batch<T>(T item) ctor public, and GenevaExporter can just call it.
2. Use Reflection directly when RuntimeFeature.IsDynamicCodeCompiled is false.
3. Address this comment in the code and make this class go away:

opentelemetry-dotnet-contrib/src/OpenTelemetry.Exporter.Geneva/Internal/ReentrantExportProcessor.cs

Lines 10 to 15 in ab7bdab

	// This export processor exports without synchronization.
	// Once OpenTelemetry .NET officially support this,
	// we can get rid of this class.
	// This is currently only used in ETW export, where we know
	// that the underlying system is safe under concurrent calls.
	internal class ReentrantExportProcessor<T> : BaseExportProcessor<T>

cc @utpilla @CodeBlanch

[utpilla]

Another approach would be to use the public ctor of Batch which takes in an array T[] and a count. We could have a thread-local array of size 1 and use that every time we need to create a Batch.

However, the best thing would be to just mark the Batch<T>(T item) ctor public.

@CodeBlanch Thoughts?

[CodeBlanch]

@eerhardt How urgent is this? If we go the route of making the ctor public in SDK it will take a bit of time to get out into a stable release so GenevaExporter can consume it.

[eerhardt]

How urgent is this?

Not very urgent. Just something that would be good to get fixed. Doing whatever is best long-term would be great. I'm not necessarily looking for a short-cut.

We could have a thread-local array of size 1 and use that every time we need to create a Batch.

I'm not super familiar with the code, so my concern might not be valid, but since Batch<T> holds directly on to the passed in array, we would need to ensure the Batch<T> insance is never passed to another thread. If it was, it could contain the wrong data.