tests/net/socket/socketpair appears to mis-use work queue APIs

[pabigot]

The only in-tree use of k_work_submit_to_user_queue() outside of its own unit tests and a footprint test is in tests/net/socket/socketpair.

In that test the queue to which items are submitted is not a user queue: it was created with k_work_q_start() rather than k_work_q_user_start(). Certain permissions on queue internal fields were granted to make the test work.

Since the entire test uses user unit tests, it's not clear whether this was meant to be a non-user test that just verifies socketpair, or was truly intended to show that the socketpair API works from both privileged and user contexts.

In any case mixing the user-mode API to submit work items with the privileged mode API to define a work queue is confusing. The test should be reworked to use one or the other.

[cfriedt]

Yeah, this one is tricky because it should work in both kernel and user space, but as you mentioned in #30110, there is currently no way to create a kernel object in a user thread but then grant permissions to another user thread to use that kernel object (afaik).

Normally, a set of file descriptors is given on a per-process / per-address-space context. Then, of course, the socket / file backend would need to map individual per-process file descriptors to the global file table.

Currently we use a global file table and global set of file descriptors in Zephyr. It's unclear as to whether any changes are planned for the socket / file backend (afaik).

Thanks for fixing the test @pabigot ;-)