runtime: eliminate unnecessary lfence while operating on queue::Local<T>

[ADD-SP]

Blocked by #7339 which fixes the CI failures caused by the new compilation error message of the new stable toolchain.

Motivation

queue::Local<T> is never been send to another thread (except while shutting down), the tail is only updated by the worker thread who owned this local queue, so any change to tail is immediately visible to the current thread.

This means the Acquire ordering is not required for loading tail while operating on the local queue.

Solution

Unsync load

Since the lfence is not required for this scenario, the atomic loading was replaced by simple pointer deref.

Remove all methods of the queue::Inner<T>

Because of the following reasons:

• All method on the Inner<T> can be implemented in differently way for Local<T> and Steal<T>
• Adding method like len_local or unsync_len creates possibilities for incorrect usage in the future which causes ABA problems in critical path.

I removed all methods on the Inner<T> and re-implement it for both Local<T> and Steal<T>.

Remove the feature gate of Steal<T>::len()

The feature gate cfg_unstable_metrics is removed for Steal<T>::len() to avoid duplicating the same code.

This doesn't seem to break anything, but if it does please let me know and I'll switch to something else.

Anything else?

Ideally, the queue::Local<T> should be marked as !Send to lower the risk that unintentionally send it to another thread, but it required the changes of the starting and shutdown logic, I will try to open another PR for this improvement.

[mox692]

I just merged #7339, so merging master should fix the ci issue 👍

[Darksonn]

Thanks.

[Toby-Shi-cloud]

I am learning lock-free structure right now. Currently I just read the implementation of this steal-queue.
This PR is great and eliminates unnecessary acquire atomic loads, but I still have a small question:
I wonder is there any reason to use unsync_load instead of relaxed atomic load, since in this implementation, the only use of unsync_load is to read tail immediately after using acquire atomic load to read head (which, I think, already prevents the optimization).