Resolve signature ambiguity in `MetricsEmitter`

[bitsandfoxes]

Coming from Unity and C# 9 I observed an

Ambiguous invocation.
Candidates are:
    EmitCounter<int>(string, int, IEnumerable<KeyValuePair<string,object>>?, Scope?)
    EmitCounter<int>(string, int, ReadOnlySpan<KeyValuePair<string,object>>, Scope?)
    all from class SentryMetricEmitter

Based on The History of C# this problem exists for projects using C# 13 (resolution priority) or older.

[linear-code]

NET-724

[Flash0ver]

Great discovery ... this was an oversight on my end.

• C# 14.0 added First-Class Span Types
• C# 13.0 added Overload Resolution Priority
• C# 12.0 added Collection Expressions

Considering

public static class Test
{
    public static void Invoke()
    {
        int[] array = { 1, 2, 3 };
        Method(array); //error CS0121: The call is ambiguous between the following methods or properties:
    }

    //[System.Runtime.CompilerServices.OverloadResolutionPriority(-1)]
    public static void Method(IEnumerable<int> numbers) {}
    public static void Method(ReadOnlySpan<int> numbers) {}
}

Invocation is potentially ambiguous:

error CS0121: The call is ambiguous between the following methods or properties: 'Test.Method(System.Collections.Generic.IEnumerable)' and 'Test.Method(System.ReadOnlySpan)'

• <LangVersion>7.3</LangVersion> through <LangVersion>12.0</LangVersion>: ambiguous
• <LangVersion>13.0</LangVersion>: ambiguity fixable via System.Runtime.CompilerServices.OverloadResolutionPriorityAttribute
• <LangVersion>14.0</LangVersion>: no ambiguity - ReadOnlySpan/Span is preferred

We also discovered that, without C# 12.0's Collection expressions, a stackalloc'ed ReadOnlySpan is not easy to produce.

In order to be compatible with lower language versions, we could / should

• use System.Runtime.CompilerServices.OverloadResolutionPriorityAttribute
  • might not work with our Polyfilling approach
  • when applying the other two options, this options might be redundant
• add SZArray-based overloads
  • KeyValuePair<string, object>[]? attributes
• remove Span-based overloads from Unity's API surface area
  • ReadOnlySpan<KeyValuePair<string, object>> attributes between #if !SENTRY_UNITY and #endif

[Flash0ver]

Additionally, I'm wondering if we can (somewhat) easily test our API against lower Language Versions.

E.g. we could stop setting LangVersion for /test/ and /samples/ projects, but in particular with our Unit Tests, this might be quite an effort.

An alternative could be a separate project, where we add API tests to these and similar methods using the Default Language Version per TFM.

Or could an AI-Skill combined with Warden examine and verify our public API shape, that we create via our "ApiApprovalTests", against various TFMs and Langauge Versions?