Description
In #2579, it was revealed that full nullable values, if you know that the nullable has a value at a certain point that calling GetValueOrDefault() is faster than .Value, despite having equivalent code, since an unnecesssary check is avoided. While obvious in retrospect given the reasoning, that is not what most of our existing code is doing.
Given that insight, in principle we should not be using .Value in any case since if at a certain point we expect that a nullable value should not be null (because we checked, or because we require it to be non-null for some other reason), we would not consider the exception thorn by the .NET framework out of .Value to be sufficiently descriptive and helpful anyway. So the hardest part of this would actually be checking that everywhere we use .Value that we do have the appropriate checks in place, since otherwise it should be a relatively straightforward replacement.
While I don't expect a measurable perf impact, since I don't think we use nullables in tight loops too often if anywhere, it certainly wouldn't hurt and would help to maintain best practices.
Not critical work for v1, since it deals with internal code.
/cc @stephentoub