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

* these functions are used in both interface management
  and bearer context management libraries

Integration: `2025.w04`

Closes #876, #896, #875, #893, and #878

See merge request oai/openairinterface5g!3226

* !3198 remove a set of compile options that don't work anyway
* !3171 Refactor SCTP Association Response Handling and E1 connection loss at CU-UP
* !3023 usrp constant and slow derive timestamp
* !3215 Remove unused code
* !3192 fix nr phy-test mode in ntn
* !3214 fix(nrLDPC_coding_t2): Miscellaneous fixes related to T2
* !3020 use ML receiver for 64 QAM UL-MIMO
* Demote error logs to debug for "PUCCH not processed"
* !3217 minor improvements in T hacks
* !3199 Add a small FAPI Hex parser utility
* !3209 Remove most of m64 type usage
* !3211 Avoid huge calloc by alloc'ing TBs independently
* !3212 F1AP IDs: Allow AddMod, fix concurrency bug
* !3152 E1 Setup enc/dec library and unit test
* !2999 Repair nFAPI in 5G
* !3210 FHI72: FDD support
* !3220 Improve RA logs

Improve RA logs

Modify existing LOG entries to include preamble index, timing advance and
estimated distance from the gNB. This makes mapping RA attempts to
physical/simulated UEs easier via sent/received preamble index or physical
distance from the gNB in scenarios with >1 UE.

FHI72: FDD support

- harmonize DL/UL PRB mapping in one get_xran_prb_map() function with support
  of mixed slot and duplex mode
- do not assume TDD by default

Repair nFAPI in 5G

Add 5G nFAPI in OAI/Make it it work.

Many commits in this branch are basically bug fixes of things that don't work
properly, such as

- check for correct conditions (e.g. instance numbers in the RAN context)
- remove artificial limitation (e.g. only one PUCCH per TDD period in the PNF)
- improve performance (reduce big mallocs, make some static buffers such as a
  global ring buffer for nFAPI messages in the PNF)
- fix bugs in nFAPI (e.g., increase maximum message size to ~64kB instead of
  1500 bytes, because the latter is way too small for many TX_data.requests in
  5G, and it will delay message arrival unduly)
- fix bugs in message enc/dec (e.g., handle FDD in config.request)
- adjust the L1 such that the condition "we run monolithic" is not necessery
  (e.g., some message numbers in nFAPI struct where reset in MAC, instead of
  L1, and this breaks when running the PNF)

There are instructions that explain how to set it up. Two CI tests have been
added, one with COTS UE and MIMO in DL+UL in TDD numerology 1 (30kHz), and a
second test with FDD mu=0 (15kHZ) in RFsimulator.

These were some old to-dos that have been addressed.

- test with COTS UE - 4x4 pipeline works good in DL, UL now also work
- test in RFsim
- make PNF status message
- make FDD in u0 work

This function packs P7 messages. At least RX_data.indication messages
might be much bigger than the global buffer that is used here. Allocate
the buffer on the stack, and make it bigger. Do not use the global
buffer, it's simply not necessary; increasing the global tx buffer size
might have negative effects elsewhere in the code.

That change might make the function reentrant. The mutex seems to only
guards the codec config. However, leave it to not introduce any
regressions as of now.

E1 Setup enc/dec library and unit test

This MR is adding a library for E1 Setup enc/dec functions:

- E1 CU-UP Setup Request
- E1 CU-UP Setup Response
- E1 Setup Failure

and relevant unit tests

F1AP IDs: Add update, fix concurrency bug

I suspect a concurrency bug: For instance, during reestablishment, the
CU needs to update the DU UE ID under which the UE is identified in the
DU. Previously, the CU would remove, then add the DU UE ID info. At the
same time, the PDCP thread might look up the information. This can lead
to asserts. Modify the code to do the update under (one) lock.

Also, refactor some code.

Avoid huge calloc by alloc'ing TBs independently

Fix real-time problems on smaller machines due to big calloc(). See the
commit(s) for more details.

Modify the existing 4x4 60MHz USRP+COTS UE test to use nFAPI. The
throughput tests remain the same.

Similar to the parent commit, make the numerology in the VNF
configurable. Unlike for the PNF change, the VNF frame/slot info is in a
per-PNF connection structure to which the "oai_integration" code has no
access. So we need to hack the nfapi_vnf_p7_add_pnf() function signature
to take the numerology, to be able to save this on a per-PNF basis.

The fact that we store this on a per-PNF basis is not strictly required,
as the VNF cannot handle multiple numerologies as of now, either.
However, we might want to extend this in the future, so it seems prudent
to store this on a per-PNF basis, so that we could start handling
multiple numerologies at the L2 without the need to change the L1 or
nFAPI code itself.

Also, the numerology is not needed except for some code that deals with
timing over nFAPI. As of now, we don't use this code (nFAPI gets a
trigger every slot, as per the VNF request, see an earlier commit in
this series), but also here, let's not make the future more complicated
by storing the numerology for each PNF now (this could always be reverted).

For 4G, put numerology 0 (15kHZ SCS), which is the SCS that LTE uses.

Fill in the dynamically received numerology, and make the numerology at
the PNF configurable, following the changes in the parent commit.

The change for the reading is somewhat of a hack, because nFAPI, as of
now, does not really foresee to store the numerology, so we fill the
numerology during the start request, when the numerlogy has been
received in the config request, but at that time, the structure for the
time information (frame/slot) does not exist yet.

At both the PNF and the VNF, introduce a separate numerology field, and
pass the numerology when converting time information using macros from
nfapi_interface.h. The actually numerology is still hardcoded to 1 (as it
was before), but the follow-up commits will put a suitable numerology.

In both cases, but the numerology next to the frame/slot information.

Similarly as the parent commit(s):
- remove hardcoding to specific numerology
- avoid conversion when we don't need it

Similar as the parent comment, remove time macros. In this particular
case, we can just pass the exact frame/slot information, instead of
squeezing it in a single integer.

The next commits will modify the time macros used in the 5G nFAPI code
to handle different numerologies. As a preparation, remove all the
usages of these macros where they really don't matter (e.g., don't
convert if we don't need to).

This file is 8y old. It does not seem to serve any purpose. Remove it.

the L1 needs both a PDU (in TX_data.req) as well instructions for
the actual transmission (in DL_TTI.req) to encode a PDSCH message. In
nFAPI, it can happen that a DL_TTI.request message has been received
(configuring the PDSCH transmission), without the TX_data.request having
reached the PNF. The L1 assumes to have the PDU.

To avoid problems, ensure that only the pair of DL_TTI.req/TX_data.req
is delivered. Otherwise, drop either message.

nFAPI has a mechanism to segment messages that are too big for transport
over a given medium (see e.g. SCF 225, section 2.3.2).

The maximum segment size of 10000 makes that for larger payloads, e.g.
TX_data.request, many small segments are to be sent. This can create or
increase delays on the transport. On the other hand, the currently only
available transport mechanism, UDP, allows to transport packets of up to
almost 65535 bytes. Correspondingly, increase the maximum segment size
so that less segments are to be created, and potentially, less delay is
to be incurred.  # Please enter the commit message for your changes.
Lines starting