[hotfix-sdk] Fix reflection breaks introduced by new Batch ctor

[CodeBlanch]

Changes

• Switch the public Batch(T item) ctor introduced in 1.10.0-rc.1 back to internal
• Introduce static Batch<T> Create(T item) instead

Details

We promoted the internal Batch<T> ctor which accepts on single item to public so that components like GenevaExporter wouldn't need to call it with reflection. The problem is the shipped versions which call it with reflection now break if the 1.10.0 SDK is present. To fix this we are putting the ctor back to internal and introducing a static method instead. The plan is to release 1.10.1 with this fix. Then obsolete/unlist GenevaExporter 1.10.0 and replace it with a 1.10.1 version which will call the new static method. We will probably also obsolete/unlist 1.10.0 SDK but need to discuss first.
 

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, 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)

[CodeBlanch]

With inlining there really is no difference calling the static vs the ctor. Demo: https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBDAzgWwB8ABAJgEYBYAKGIAYACY8gOgCUBXAOwwEt8YLAMIR8AB14AbGFADKMgG68wMXAG4aNYgGYmpBkIYBvGgzNNdAIWwYwACwA8zOgD4GAVVy8uAcwCSPDJc2JIAFACUxqbmMcQA7AxcMADuoQBEdjCSkhAMydCSACZp4RrUMQC+0WbVFgzWto7Obp7ePrIYNsoRUeUx5vH1NvZO5K7CsDYw6ZnZuflQRSVllTG1tToMk4UQXJIAngy4GFAcYBhDjQ4AKi61McmZsAzXDCB6tSZ9/QxiULwKKZbGDYHZ7Q7XAD8DF4GBg+AYAF5Ehxsisfv17uYANoAWRgGDsEEKfnEYXxhOJpLEkgA8mI+LtcCwAII+HywXBeBQwAKSbxtcIAXSxZk2zCQlxGtwMkzhoVesPh4VFvQx/RZUB8HAEPAAcqjJABRBAqBm8XYsa52KAQZJ+ABmBuyoSV+FKmm+6qYCSSySljlurrh7vRPwq3vMnvV3jhUGCkgDCphIZVXpiX0jZkJvGZbqRKfhYf6VXTGNVm1efhDSLcObzIYAhMXSxUgA

[Kielek]

I do not think that it is good idea. It is a risk on the consumer side if they are relaying on non-public stuff.
I doubt that it is big adoption of 1.10.0 in the wild, but introducing binary breaking changes on public contract is something we should avoid.

EDIT: if it affects only GenevaExporter, lets make some messages internally in MS that it requires bumping both packages together.

[reyang]

...but introducing binary breaking changes on public contract is something we should avoid.

+1

[alanwest]

I do not think that it is good idea.

I agree with @Kielek. The design of our public APIs should not be influenced by libraries that use our packages in unorthodox ways (e.g.,, accessing non-public constructors). This pattern of a static Create method doesn't feel like a pattern we use very widely in the SDK.

Originally, I supported making the constructor public because I think it is reasonable to give extension authors access to things we use in the extensions we ship with the SDK like the simple export processor. That is, while the Geneva exporter motivated the need, it is not what motivated my decision.

[alanwest]

Blocking due to concerns raised by @Kielek and myself.

[reyang]

...but introducing binary breaking changes on public contract is something we should avoid.

+1

should -> must