std: simplify SGX's UnsafeList

[joboet]

Fixes #160603
Fixes #114581

This fixes the soundness issues in SGX's UnsafeList by removing the use of a dummy node in the doubly-linked list, which would have required either UnsafePinned or pointer laundering tricks to make sound (c.f. #160641). In addition, the code is now much more careful when it comes to creating mutable references to whole entries to avoid invalidating any shared borrows of the values when modifying lists.

CC @jethrogb

[rustbot]

r? @clarfonthey

rustbot has assigned @clarfonthey.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 13 candidates
• Random selection from ChrisDenton, JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

[jethrogb]

This is a very intrusive change that changes a lot about the inner workings of the list as well as the list API. I don't really support making this kind of change.

[joboet]

Given that both UnsafeList and WaitQueue are private I don't see how this would be a problem?

[jethrogb]

The problem is that this needs to be very carefully designed and reviewed because it can easily lead to fundamental concurrency issues if there are any bugs. I don't see a good reason for such an intrusive change given there are much simpler fixes.

[theemathas]

I consider the pointer provenance laundering stuff to be a very complicated fix, so I don't think the "there are much simpler fixes" argument really holds.

[jethrogb]

The entire code can be reviewed and fully understood assuming launder is a no-op.

[ds84182]

The entire code can be reviewed and fully understood assuming launder is a no-op.

Launder is a runtime no-op, but is very significant at compile time as any issues with it will lead to silent miscompilations.