tx_next was increased only when all segments of an SDU were sent to
lower layers. This may lead to a situation where the receive entity
transmits a control PDU that is rejected because it sets its ACK to
tx_next+1 (if all segments were not transmitted when the control PDU
is sent).

What is done now is to increase tx_next as soon as we send the first
segment of an SDU to lower layers. A control PDU received from the
receive entity is now accepted and processed.

Specifications (38.322 5.2.3.1.1) say to increase tx_next when the
RLC entity receives an SDU from upper layers. But for us, since the
buffering of SDUs is done in the RLC layer and since the buffer size
may be big, we may increase tx_next too much. The choice has been
made to increase it only when we transmit an SDU to lower layers.
We may change this logic if needed. (But it won't be simple.)

integration_2023_w38

See merge request oai/openairinterface5g!2354

* !2296 rfsimulator optimization
* !2344 NR UE DCI config small fixes
* !2342 Fix for PBCH decoding
* !2347 Handle NAS registration accept inside NAS downlink
* !2350 Tutorials: upgrade UHD version to 4.5.0.0
* !2351 NR UE HARQ fix
* !2304 Use F1 internally: F1 Setup
* !2306 nr_ulsim and nr_dlsim logging and help modifications
* !2305 NR UE RRC bearers management
* !2353 Fix documentation references to "telnetsrv"

Merge remote-tracking branch 'origin/add-registration-accept-inside-nas-downlink' into integration_2023_w38

- Reorder help messages
- Add possibility to log results per SNR to CSV file with `-X` or `-Z`
- Reformat files
Co-authored-by: MoadMaroufi <maaroufi.moaad321@gmail.com>
Co-authored-by: francescomani <email@francescomani.it>
Co-authored-by: Robert Schmidt <robert.schmidt@openairinterface.org>

- store the assoc ID of a UE at the RRC
- if F1 receives an SCTP shutdown, it removes the endpoint
- F1 will also send an "F1 Lost Connection" message to the RRC
- it is not yet possible to reconnect a DU after it had already been
  connected at the CU, since the CU F1AP task will try to rebind GTP,
  which fails

- Free the memory
- for NGAP NAS UL and NAS First request, allocate memory to avoid
  use-after-free errors

- Forward UE capabilities in F1 handlers
- Store at MAC
- Update CellGroupConfig with UE Capabilities of the UE

- MAC creates CellGroupConfig and sends to RRC
- the RRC does not manually update the CellGroupConfig
- MAC handles the RRC processing timer

In this commit, any updates to the CellGroupConfig previously done at
the RRC don't work. In other words, MIMO etc don't work; this is
implemented in the next commit.

Note that the change to take out spCellConfig during reestablishment is
because after reestablishment, as per spec (38.331 5.3.7.2), the UE
should drop the spCellConfig, which we generate by default on the first
UE connection.

Furthermore, add a new variable apply_cellgroup to signal if, after RRC
processing timer, we wish to apply the CellGroup. In some situations,
e.g., Msg.4 ack, we do not want to apply the CellGroup, because for
instance in reestablishment, we await for a reconfiguration of cellgroup
that would be triggered too early.