Fix invalid access of Target in SafeCredentialReference

[aik-jahoda]

The SafeCredentialReference derive from CriticalHandleMinusOneIsInvalid however it didn't owerride IsInvalid nor IsClosed and the behaviour of those method are not reflecting the real Target state.

I removed this inheritance so the problemathics methods are no longer valid and it pointed into problematic usage of SafeCredentialReference which is fixed now.

Fixes #34337

[ghost]

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[wfurt]

you may need to rebase or merge from upstream @aik-jahoda

[aik-jahoda]

@wfurt, thanks for the notice. All tests are passing now.

[stephentoub]

How would creds be null here? If there's actually a concern that cached.Target might change from non-null to null concurrently, you can move the creds = cached.Target line to above the previous if block, and then use that creds in the above if check... then it definitely won't be null here.

[stephentoub]

Also, doesn't CreateReference already check for IsClosed and IsInvalid and return null if either is true? Why do we need to duplicate those checks here?

[stephentoub]

@aik-jahoda, are you still working on this?

[aik-jahoda]

@stephentoub not actively now. However this is on our test failure list and I expect it will be prioritised soon.

[aik-jahoda]

I continue on this PR to resolve the handles issue.

[aik-jahoda]

I run the test in loop for several days with any failure. It is ready to merge and we will observe possible failures in our weekly CI report.

[wfurt]

LGTM

[ViktorHofer]

@aik-jahoda is the result.txt file that was checked into this PR necessary?

[wfurt]

no, it is not. we miss it in the review IMHO as GitHub would not show binary (utf-16) diff @ViktorHofer

[ViktorHofer]

@aik-jahoda can you please send a PR to remove the file from main?