Changes to AsyncLocal usage for better lazy loading performance

[henriquewr]

Changed AsyncLocal to ThreadId for better performance
Fixes #35832

[roji]

@henriquewr I'm not very familiar with that particular part of the code, but async code is executed across different threads - every time the code awaits, it may continue executing on a different thread. So checking the thread ID is probably wrong here - the AsyncLocal is being used to propagate the state across different threads.

But I may be misunderstanding things here. @AndriySvyryd assigning this (and #35832) to you as you know the area best.

[AndriySvyryd]

I agree with @roji, for recursive lazy loading async calls the thread might change between the outer call and the nested call leading to a deadlock. If the issue is indeed caused by AsyncLocal allocations, consider using a static instance for the case when there's only one entry in _isLoading.

[henriquewr]

@AndriySvyryd
I removed the threadId and now im using the static AsyncLocal
I didn't realize until now that I don't need to create a new AsyncLocal instance in order to get a unique value on this context

[AndriySvyryd]

With this approach there still might be a deadlock issue with different lazy loaded navs trying to load the same nav in a nested call, but this use case is probably so rare that we don't need to worry about it.

[AndriySvyryd]

Thanks for your contribution!

[OwnageIsMagic]

@maumar the resulting diff doesn't use ThreadId and this wrong title propagated to net10 release notes.

[stevendarby]

Came here from the release notes too

[roji]

Corrected the PR title and submitted dotnet/EntityFramework.Docs#5054 to fix the what's new docs.