Keep MemberNotNullAttribute in sync for src <-> ref

[ViktorHofer]

Contributes to #58163

Enable ApiCompat protection for the MemberNotNull attribute.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Contributes to #58163

Enable ApiCompat protection for the MemberNotNull attribute.

Author:	ViktorHofer
Assignees:	ViktorHofer
Labels:	area-Infrastructure-libraries
Milestone:	-

[stephentoub]

Why are we doing this? It would only be relevant if the field in question was public/protected; I don't believe any of these are. This is leaking implementation details into the ref.

[ViktorHofer]

See #66090 and please contribute to that discussion.

[bartonjs]

This is just noise in the ref.cs files, and creates situations which violate the "you shouldn't be changing this file without an appropriate api-approved issue" rule that goes along with them.

Whatever tooling we find ourselves using now or in the future can't put these in these files.

If we use roslyn to output these files as source, we can post-process them. But, as @stephentoub points out in the discussion issue, we don't want them in the ref.dll, either. So, until/unless we can get knobs in Roslyn to control that, our best Roslyn-powered flow would be to output the .cs, post-process it, and check it in.. then build that. Basically what we have right now with GenAPI (except we get to stop adding in language feature analysis).

[ViktorHofer]

Thanks for taking the time to share your feedback Jeremy.