This commit implements retrieval of 5G-S-TMSI from Parts 1&2, or the
entire 5G-S-TMSI, depending on what the UE sends. Further, if it has
been retrieved, print a log of all constituent parts of it.

The UE-specific variable ng_5G_S_TMSI_Part2 is not needed, as we compute
the full 5G-S-TMSI as soon as we have Part2 (and 1).

The correct forwarding to the core is implemented in the following
commit.

We did not give a cause value, and therefore NGAP's "PDU sessions
failed" encoding failed. Give a cause value in all cases, so that this
cannot happen anymore.

To prevent against this, put an AssertFatal() into the encoder that
stops if an internally sent message does not have a correct cause value
(we can at least select a default).

Print an info message for all failed PDU sessions.

In rrc_gNB_send_NGAP_INITIAL_CONTEXT_SETUP_RESP(): if a PDU session is
already established, don't count it as failed.

In all these cases, we simply continue with processing; it therefore
seems that these are more warnings than errors.

- Demote logs judged unimportant to debug
- Indicate UE for UL failure
- set_QoSConfig(): correct log

If we are in one of these procedures, we basically must be in SA mode,
everything else is illogical. It also does not seem plausible to check
for this, as it is not apparent why only these couple of calls should
not be executed if not in SA. Hence, remove.

This implementation might work, but it simply triggers RRC setup on the new
DU when we might send a RRC reestablishment speeding up the whole
connection setup. For this:

- we should send the F1 UE context setup to the new DU
- we should still do the reestablishment, containing the reestablishment message

The latter should be sent once we received the F1 UE context setup
response. We don't need a new context. send a release to the old DU (and
don't release our own context!!).

We might also send the reestablishment to the UE encapsulated with the
F1 UE context setup response. Need to investigate if this is feasible
(because if the DU rejects [can that happen here?], the UE will still
send reestablishment complete -- what then?).

Also, we would need to send the E1 bearer context modification to the
CU-UP.

Keeping track if AS security is activated. This is important for a later
commit, where we use this to decide if we send a F1 UE Context Setup Req
with security command after receiving the E1 bearer context setup
response. The corresponding AssertFatal() removed in the same commit
implementing PDU session handling in NGAP Initial UE Context Setup.

38.401 Sec 8.1 asks for sending the Initial Context Setup Response after
a reconfiguration happened. Therefore, we can never send this message
directly from the handler in the Initial Context Setup Request

Integration: 2024.w04

See merge request oai/openairinterface5g!2535

* !2522 Integration of O-RAN 7.2 FH using OSC xRAN library
* !2416 fix-ue-scheduler-multi-thread-storage-list-mutex-protection
* !2488 LDPC T2 card encoding: rate matching and interleaving on the T2 card
* !2497 Read NoS1 bearer configuration from gNB-generated file
* !2518 Extension of E1AP procedures
* !2533 This limits PUCCH payload to 11 bits, 7 CSI + 3 ACKNACK + 1 SR maximum.
* !2526 prepare MSG3 in advance at RRC UE
* !2451 MAC procedures to handle DLSCH allocation type 0
* !2525 NR UE fix for function to find PUCCH resource set
* !2536 Improve Precoding Matrix computation taking in consideration the DCI format
* some documentation+config file updates for 7.2
* !2501 Improvements for NR implementation of timers
* !2531 Fix unit test build and build unit tests in CI

- PUSCH target increase: lower PUSCH target requires !2373
- sdr_addrs is USRP-specific, not needed for O-RAN

Merge remote-tracking branch 'origin/NR_UE_dlsch_rescource_allocation_type0' into integration_2024_w04

Merge remote-tracking branch 'origin/NR_UE_prepare_msg3_payload_in_advance' into integration_2024_w04

Merge remote-tracking branch 'origin/NR_UE_reworking_NOS1_bearer_configuration' into integration_2024_w04