Reduce one level of indentation, and explain why we wait for
physide_dl_tti callback.

first_rx_set is polling-specific: it makes the polling loop wait to only
check the frame/slot counter once we set it for the first time. However,
that is equivalent to checking the frame/slot directly, which will also
be 0 in the beginning.

first_read_set seems to have the function of making frame/slot time
advance only if we started to read the samples in
xran_fh_rx_read_slot(). I interpret that as "only advance the time if
the gNB is reading from xran", which does not make sense to me, because
xran advances the time anyway. Also, polling would not notice, and
no-polling would simply warn about double messages. So the outcome is
likely the same, whether first_read_set is set or not.

I checked in multiple CI runs; it happens that first_read_set is always
set already when oai_xran_fh_rx_callback() is called anyway.

xran_fh_rx_read_slot() uses polling (a loop over cnt++) to wait for the
next frame/slot. The reasons I have been told is "it does not work
differently", or "there are real-time problems". None of those seem to
be true; by default disable polling, and use the queue instead.

It is possible to enable polling with the cmake option
OAI_FHI72_USE_POLLING=ON. Documentation has been updated to inform about
this change.

The queue L1_rx_out was in place to keep RX/TX processing relatively
"close" to each other (in terms of time, since in RFsim, they might
advance faster than realtime; see also parent commit). This lead to a
memory leak in radios that do not use ru->feprx (no front-end processing
for RX, e.g., PRACH), as the code to read the L1_rx_out messages was
inside a block of if (ru->feprx). Move it out so that the queue is
always read and messages are freed to eliminate the memory leak, and
remove the workaround for FHI72 to avoid this memory leak.

This also allows to run RFsim when compiling FHI72, which was not
possible before this commit.

Closes: #812

Some radios (e.g., RFsim) can run faster. A mechanism has been put in
place to keep RX/TX frame/slot numbers not too far from each other.
Refactor in a separate function with documentation to make this clearer.

Move the extern definition to the header, to avoid type errors.

Integration: `2025.w06`

See merge request oai/openairinterface5g!3248

* !3202 Simplify usage of the old segment decoding libraries with the slot coding interface
* !3240 Fix typos in NR_SA_Tutorial_OAI_multi_UE.md
* !3242 Period based phytest bitmap
* !3238 Refactor tun_if.h
* !3000 Improvements for NR dlsim and ulsim
* !3239 Remove inexistant SIMD instruction
* !3246 Deadlock avoidance in rfsimulator
* !3251 nFAPI: make 4-layer on 100MHz work
* !3243 Reset E1 UE contexts after E1 Setup Response
* !3245 Added Support of 35Mhz,45Mhz,70Mhz Bandwidth
* !3219 E1AP enc/dec lib improvements

E1AP enc/dec lib improvements

This MR is including some fixes and improvements for the E1AP library,
focusing mostly on Bearer Context Management:

- struct reorganization: split setup and modification request messages
  into distinct structures, ensuring compliance with 3GPP TS 38.463
  specifications
- add encoding/decoding sub-functions for different IEs
- improvements to Bearer Context Management: Implemented various
  improvements to the E1 Bearer Context Setup Response and Request,
  including the adoption of encoding/decoding sub-functions for
  different IEs
- use lib functions whenever need (e.g. cp_bearer_context_setup_request
  in cucp_cuup_e1ap.c)
- handle optional struct members as pointers
- updated copy/equality check utility functions

EDIT: The MR is also including the changes from !3222 (closed):

> While testing E1 with security enabled for DRBs, it was found that
> data traffic was not functional.
>
> The problem was that security settings were modified in the PDCP
> reestablishment happening when receiving Bearer Context Modification
> Request.
>
> So some restructuring was done.
>
> The actual fix is in 18176297, the others are for support. Basically
> we introduce a boolean to check if the security settings are present in
> Bearer Context Modification Request and we change PDCP security settings
> only if they are.
>
> (Note that in OAI CU security settings are not sent in Bearer Context
> Modification Request, so we could also remove all this, but we need to
> be compatible with other cu-up and/or cu-cp.)

Added Support of 35Mhz,45Mhz,70Mhz Bandwidth

Added Support of 35Mhz,45Mhz,70Mhz Bandwidth for 30Khz Subcarrier
Spacing, Also added 35Mhz, 45Mhz bw for 15Khz Subcarrierspacing.

Referred Spec TS 38.101 v18.6.0 section 5.3.2, table 5.3.2-1

Reset E1 UE contexts after E1 Setup Response

38.463 sec. 8.2.3 says

> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes
> like a Reset procedure would do.

Hence, delete all contexts after reception of E1 Setup Response. This
minimizes a risk of receiving an E1 bearer setup req for an existing UE,
which currently leads to an assert [we trust the CU-CP does not send the
same UE ID twice, as we only "mirror" the existing UE ID].  After this
MR, this is what happens if these entities fail:

- CU-CP fails: all context lost implicitly, upon reconnection, both DU
  and CU-UP reset all contexts (like "start from zero")
- DU fails: CU-CP triggers NGAP UE context release request immediately
  (radio connection with UE lost), all UE contexts attached to this DU
  cleared (like "start from zero" for affected DU)
- CU-UP fails: initially, nothing (UE has no user plane); upon
  reconnection of CU-UP, CU-CP triggers NGAP UE context release request
  (cause radio connection with UE lost) and sends F1 Reset to DU, all UE
  contexts associated to this DU cleared (like "start from zero")

for the last case, a possible improvement could be to use the F1 Reset
message to only clear affected UE conetxts. I chose not to do this,
because this MR is very big now already, and possible "victim" UEs
that were not at that CU-UP will reconnect as well

In Bearer Context Modification Request, the security information
field is needed only if we change the PDCP algorithms/keys. Since we
don't, no need to pass it.

Let's keep the old code, maybe the current understanding of the
specifications is wrong.

If the Bearer Context Modification Request does not contain security
information, the PDCP entity shall keep the currently configured security
settings.

Passing -1 for ciphering_algorithm and integrity_algorithm is the way
to implement this logic.

Check if the IE is memory allocated to deal with presence/absence of this information
element in Bearer Context Modification Request and add encoding/decoding
in the code.

Note that for decoding the integrity settings may be absent, in which
case we consider NIA0 to be used (no integrity protection). To be refined
if needed.

And for encoding, we always encode integrity settings, even if it's NIA0.
May also be refined if needed.

This was not a big problem, but we were advertising wrong
algorithm and deriving keys using this wrong algorithm in case
DRB ciphering and/or integrity was not active. (Say SRBs
are configured with NIA2 but DRBs are configured without
integrity, we would advertise NIA2 and send the integrity
key derived for NIA2, instead of NIA0 for both.)

It was not a problem because in the PDU Session Resource To Setup
item, there is "securityIndication" which we use to effectively
activate/deactivate the ciphering and/or integrity.

But it did not look clean to see a SecurityInformation with
incorrect data when inspecting the message in wireshark.

So let's use the correct values.

We could also not include the SecurityInformation if both ciphering
and integrity are not used, and only include ciphering if integrity
is not used (because integrity settings are optional).

But then if only integrity is used, we still need to include
ciphering, setting algorithm to NEA0 (no ciphering), because
the ciphering settings are always included.

This logic is too complex, let's use the simple one to always
include SecurityInformation with NEA0 and/or NIA0 if ciphering
and/or integrity is not activated.

As in deba3ae0 ("Reset CU-UP E1 UE contexts after E1 Setup
Response"), the CU-CP should reset the E1 UE contexts after E1 Setup
Response. 38.463 sec. 8.2.3 says

> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes like
> a Reset procedure would do.

In the case of CU-CP, this is a bit more complicated. More precisely, we
need to wait for the CU-UP to be available again before informing the DU
about the loss (implemented via an F1 Reset message), because otherwise,
the UE might reconnect immediately, before the CU-UP is online again.

Hence, on connection loss, we mark affected UEs (by setting their E1
association ID to 0); as long as the CU-UP does not connect, nothing
will happen (but UEs don't have user plane). Upon CU-UP connecting
again, we request release of the UEs via NGAP (similarly to what is done
if the DU goes offline, see invalidate_du_connections()), free the UE
contexts locally, and send an F1 Reset message to the DU, because
38.473 sec 8.2.1.2.1 says

> a failure at the gNB-CU [...] has resulted in the loss of some or
> all transaction reference information [...] a RESET message shall be
> sent to the gNB-DU.

The core should accept and send an NGAP release command message; since
no UE contexts are to be found (already deleted), the CU-CP will just
send a release complete (together with some warnings).

It might be possible to more gracefully handle the situation (e.g., as
described in 38.401 section 8.9.5 "Change of gNB-CU-UP"), but

- we lack the PDCP SN exchange
- the current procedure has the advantage of being equivalent to
  "restart of the entire gNB", with less downtown.

The next commit will use rrc_remove_ue() to delete a CU(-CP+-UP)
context. However, we don't send NGAP UE context release at that moment
(we will instead *request* the release); more generally, it's not clear
that every user of rrc_remove_ue() wants to actually send this message.
Hence, refactor the code by separately calling
rrc_gNB_send_NGAP_UE_CONTEXT_RELEASE_COMPLETE() where appropriate.

* Add enc/dec/cp/eq sub-functions to E1 library and adopt in stack
  * eq_drb_to_mod
  * encode_dl_up_parameters
  * decode_dl_up_parameters
  * e1_decode_snssai
  * e1_encode_snssai
  * eq_security_ind
* Check result of enc/dec functions in Bearer Context Setup enc/dec libs

* this is necessary to enable the error logs in the E1 libs
* also, updated the define name in the E1AP lib

Bearer context setup request and modification request messages
differ in various IEs according to 9.2.2 of 3GPP TS 38.463, e.g.
the Bearer context setup request does not contain a list of
DRBs to modify and does not contain an UP TL configuration.

Thus, the goal of this commit is to split the setup request message
and the modification request into two different structs:
* adopt e1ap_bearer_mod_req_t where necessary (e.g. fill_e1_bearer_modif)

Also, reorganized existing struct members according to specs:
* remove irrelevant struct members from the setup request
* group members from the same IEs into structs
* set optional struct members IEs as pointers
* add and adopt enc/dec/cp/eq lib functions for single IEs
* add UP_TL_information_t struct with TEID and TL address info and adopt in stack
* use int instead of long for count types
* update the relevant copy/equality check utility functions

Extra:
* add a function to handle Security Information in RRC in the process
* add create_up_tl_info and adopt in unit tests

nFAPI: make 4-layer on 100MHz work

5G nFAPI headers specify 32 bits for the length field, so use it also
when segmenting messages. This should stabilize 4-layer MIMO operation
on 100MHz with nFAPI.

Deadlock avoidance in rfsimulator

This change introduces a countermeasure for deadlock in rfsimulator. The
deadlock happens when all entities are waiting for new data to come in,
and happens with 2+ clients, when a new client connects. I think this
issue is due to ordering of fullwrite calls, resulting in out-of-order
delivery of packets and eventually trashing the packets on the receiving
side. The out-of-order delivery warnings are printed just before the
system deadlocks but I have not found a better solution so far. The
workaround makes the server never lock up permanently by ignoring the
client failure to write on time after 10 tries.

This was tested locally for both UE as server and gNB as server and
works correctly, causing the deadlock to clear and the added log to be
printed several times when the deadlock is detected, after which the
system goes back to normal.

I have some gdb output of the executables during deadlock:

    UE:

    $7 = {conn_sock = 98, lastReceivedTS = 3226163740, headerMode = true, trashingPacket = false, th = {size = 13184, nbAnt = 1, timestamp = 3226150556, option_value = 0, option_flag = 0}, transferPtr = 0x7f6a500018a8 "\200\063", remainToTransfer = 24,
      circularBufEnd = 0x7f6a503b3ac0 "", circularBuf = 0x7f6a501f1ac0, channel_model = 0x0}
    (gdb) p t->buf[5]
    $8 = {conn_sock = 97, lastReceivedTS = 0, headerMode = true, trashingPacket = false, th = {size = 0, nbAnt = 0, timestamp = 0, option_value = 0, option_flag = 0}, transferPtr = 0x7f6a50001900 "", remainToTransfer = 24, circularBufEnd = 0x7f6a50575ad0 "",
      circularBuf = 0x7f6a503b3ad0, channel_model = 0x0}

    nextRxTimestamp 3225937740
    nsamps = 30720

    gNB 1:
    (gdb) p t->buf[0]
    $4 = {conn_sock = 95, lastReceivedTS = 3226026876, headerMode = true, trashingPacket = false, th = {size = 1, nbAnt = 1, timestamp = 3226026875, option_value = 0, option_flag = 0},
      transferPtr = 0x7f8dfc003ab8 "\001", remainToTransfer = 24, circularBufEnd = 0x7f8e1c3ff010 "", circularBuf = 0x7f8e1c23d010, channel_model = 0x0}
    nextRxTimestamp 3225996956

    gNB 2:
    lastReceivedTS = 3226026875
    $2 = {conn_sock = 95, lastReceivedTS = 3226026875, headerMode = true, trashingPacket = false, th = {size = 1, nbAnt = 1, timestamp = 3226026875, option_value = 0, option_flag = 0},
      transferPtr = 0x744898003ab8 "\001", remainToTransfer = 24, circularBufEnd = 0x7448bc2e7010 "", circularBuf = 0x7448bc125010, channel_model = 0x0}

    nextRxTimestamp 3226026875

As you can see all executables are in have_to_wait state.

f1ap_lib_common should help with common message enc/dec inside lib/, and
not be used directly.

38.463 sec. 8.2.3 says

> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes like
> a Reset procedure would do.

Hence, delete all contexts after reception of E1 Setup Response. This
minimizes a risk of receiving an E1 bearer setup req for an existing UE,
which currently leads to an assert [we trust the CU-CP does not send the
same UE ID twice, as we only "mirror" the existing UE ID].

Refactor into remove_ue_e1(), to be used in the next commit, independent
of e1_bearer_release_cmd().