libc/socket: add unix socket tests (accept, connect, recv MSG_PEEK)

[adamgreloch]

JIRA: RTOS-862, RTOS-877

Description

Adds unix socket accept/connect tests, both blocking and non-blocking, as well as a small test for proper recv(MSG_PEEK) behavior.

Motivation and Context

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: (list targets here).
  ia32-generic-qemu

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work (list the PRs, preferably in merge-order).
  posix: fix unix socket accept/connect, add their nonblocking variants, handle MSG_PEEK in recv phoenix-rtos-kernel#572
• I will merge this PR by myself when appropriate.

[nalajcie]

a few generic remarks:

• tests should not print extra info apart from the assertions/test results (we might add verbose mode in the future if needed) - it breaks the trunner state machine (especially printing lines without \n)
• declare functions as static if you don't want to use them outside of this compilation unit
• using unity you can't ASSERT in different thread/process than the main one (failed assertion uses longjmp) - the errors from other threads/processes need to be read in a different way - see if it's feasible to use unity the use cases you want to test (the other option is to make separate test with custom harness)

[adamgreloch]

a few generic remarks:

• tests should not print extra info apart from the assertions/test results (we might add verbose mode in the future if needed) - it breaks the trunner state machine (especially printing lines without \n)

Done

• declare functions as static if you don't want to use them outside of this compilation unit

Sure. Should I also make the functions for previous tests static in this test file that seem to be local to the test suite (not declared in any header)?

• using unity you can't ASSERT in different thread/process than the main one (failed assertion uses longjmp) - the errors from other threads/processes need to be read in a different way - see if it's feasible to use unity the use cases you want to test (the other option is to make separate test with custom harness)

I wasn't aware of that, thanks. Hopefully this is related only to asserts, but FAIL() is fine (as done in previous tests)?

[github-actions]

Unit Test Results

7 759 tests  +36   7 041 ✅ +33   37m 53s ⏱️ +9s
  443 suites ± 0     718 💤 + 3 
    1 files   ± 0       0 ❌ ± 0 

Results for commit bcbf2f6. ± Comparison against base commit a20b474.

♻️ This comment has been updated with latest results.

[nalajcie]

a few generic remarks:

• tests should not print extra info apart from the assertions/test results (we might add verbose mode in the future if needed) - it breaks the trunner state machine (especially printing lines without \n)

Done

• declare functions as static if you don't want to use them outside of this compilation unit

Sure. Should I also make the functions for previous tests static in this test file that seem to be local to the test suite (not declared in any header)?

Yes, I think so.

• using unity you can't ASSERT in different thread/process than the main one (failed assertion uses longjmp) - the errors from other threads/processes need to be read in a different way - see if it's feasible to use unity the use cases you want to test (the other option is to make separate test with custom harness)

I wasn't aware of that, thanks. Hopefully this is related only to asserts, but FAIL() is fine (as done in previous tests)?

I don't think so, checking call stack it goes down to longjmp, so the current code is also invalid.