[#436] Split up the sig handler into non fatal and fatal signals

[elfenpiff]

Notes for Reviewer

The SignalHandler registers in the beginning every signal to keep track of them so that the user can later acquire them via an internal atomic variable. The problem is, that by default it also registers SIGSEGV and other fatal signals. If such a signal is emitted in turns into an infinite loop where the signal callback is called.

This can be mitigated by splitting up the FetchableSignals into FatalFetchableSignals (e.g. SIGSEGV, ...) and NonFatalFetchableSignals (SIGINT, SIGUSR1 ... ).
Certain operations are only allowed for NonFatalFetchableSignals, like acquiring the last signal that was emitted. Also the SignalHandler only registers NonFatalFetchableSignals by default so that the user can later acquire the signal that was emitted. For FatalFetchableSignals it would not make sense since then the callback of the signal is the last thing the program executes.

Pre-Review Checklist for the PR Author

1. Add sensible notes for the reviewer
2. PR title is short, expressive and meaningful
3. Relevant issues are linked in the References section
4. Every source code file has a copyright header with SPDX-License-Identifier: Apache-2.0 OR MIT
5. Branch follows the naming format (iox2-123-introduce-posix-ipc-example)
6. Commits messages are according to this guideline
   • Commit messages have the issue ID ([#123] Add posix ipc example)
   • Commit author matches Eclipse Contributor Agreement (and ECA is signed)
7. Tests follow the best practice for testing
8. Changelog updated in the unreleased section including API breaking changes
9. Assign PR to reviewer
10. All checks have passed (except task-list-completed)

Checklist for the PR Reviewer

• Commits are properly organized and messages are according to the guideline
• Unit tests have been written for new behavior
• Public API is documented
• PR title describes the changes

Post-review Checklist for the PR Author

1. All open points are addressed and tracked via issues

References

Relates to #436

[codecov]

Codecov Report

Attention: Patch coverage is 52.77778% with 17 lines in your changes missing coverage. Please review.

Project coverage is 78.93%. Comparing base (e9332a0) to head (9ebf521).
Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
iceoryx2-bb/posix/src/signal.rs	52.77%	17 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #448      +/-   ##
==========================================
- Coverage   79.01%   78.93%   -0.09%     
==========================================
  Files         196      196              
  Lines       23258    23283      +25     
==========================================
+ Hits        18378    18379       +1     
- Misses       4880     4904      +24     

Files with missing lines	Coverage Δ
iceoryx2-bb/posix/src/signal.rs	74.72% <52.77%> (-4.79%)	⬇️

... and 5 files with indirect coverage changes

[orecham]

Nothing to change, but just out of curiosity - why the distinction of being Fetchable ? What is a NonFetchableSignal ?

[elfenpiff]

For NonFetchableSignal you cannot register a custom callback via sigaction. For instance SIGKILL does not send anything to the process but the OS directly kills the process without informing it.