Removed @Nullable annotation to maintain binary compatibility with 1.49.0 for Kotlin users

[bidetofevil]

This reverts PR #7271, thereby addressing #7358, which broke binary compatibility in for Kotlin users in release 1.50.0

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.84%. Comparing base (cc7d085) to head (8a7fa09).
Report is 49 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #7359      +/-   ##
============================================
- Coverage     89.87%   89.84%   -0.03%     
+ Complexity     6899     6897       -2     
============================================
  Files           786      786              
  Lines         20793    20793              
  Branches       2026     2026              
============================================
- Hits          18687    18682       -5     
- Misses         1465     1468       +3     
- Partials        641      643       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bidetofevil]

I restored this despite it being inconsistent with the API, but I didn't want to make any additional changes on a PR that is essentially a revert.

[jkwatson]

Thanks! We should release a patch to fix this.

[bidetofevil]

Let me know when y'all plan to merge this

[jack-berg]

I don't think we should merge this.

Reasoning:

• This doesn't affect users, only implementations of the API.
• At the otel project level, we're actually not under any obligation to ensure API implementations are not broken across releases. If we were, then interfaces would be unable to be evolved with additional methods in languages that don't have features like java's interface default implementations. In java, we do provide default implementations of interfaces as a convenience, but there's an argument that we're doing a disservice by obscuring / hiding API additions from implementations who would otherwise receive compilation errors upon upgrading.
• This change of an argument from non-null to null is an edge which seems specific to kotlin implementations of the API, and my read of VERSIONING.md is that we don't make any guarantees about this type of thing. I don't think we're obligated to patch this. I'm more open to amending the VERSIONING.md, but also am not in favor of that.
• Overall, I like that attribute values are now @Nullable and think it meaningfully improves the API ergonomics. That harm caused by this introduction seems small and localized to kotlin implementations of the API, of which there may just be one in existence. From my perspective, the benefit exceeds the harm by quite a large margin.

[jack-berg]

Closing since I haven't heard any strong strong push back against my comment