It is difficult to keep track of a "UE lifecycle". To make this more
easy, add LOG_A at major UE RRC messages.

It will be used in the next commit

This commit removes many logs that just show memory addresses, indices,
etc., which, I presume, do not mean anything to the "average user" and
developers alike.

Most printf() do not show much information (like only a "X is ready",
which is not useful for subsystems). Remove those. The rest, make them
LOG_D.

Integration: `2024.w43`

Closes #769 and #841

See merge request oai/openairinterface5g!3069

* !2994 Refactor file descriptor handling in rfsimulator
* !3010 Fix heap overflow in websrv
* !3043 CI: Update RAN-gNB-N300-Timing-Phytest-LDPC test cases
* !3060 process registration reject in UE
* !3062 fix nr rlc tests
* !3067 Bugfix: Fill QFI for N3 GTP messages
* !3057 Bugfix in ue pusch mac pdu creation
* !3068 getopt() returns int
* !3056 F1AP Enc/Dec Library follow-up
* !3064 T: don't check argument in optimized version of T IDs
* !2786 Add F1 Handover procedures
* !2980 Refactor NAS 5GS PDU Session Establishment Accept handling and other NAS improvements
* !3063 Update yaml-cpp dependency handling
* !2989 NR gNB scheduler improvements for BWP operation

This MR removes limitations on BWP scheduler operation for which only
the information from the first UE of the list was taken into account. To
do so, I moved the VRB map check for DL and UL scheduler out of the
preprocessor and in the scheduler itself.

Closes: #769

Update yaml-cpp dependency handling

- Added CPM fallback in case package is not found automatically.
- Using yaml-cpp::yaml-cpp target instead of yaml-cpp to silence
  deprecation warnings on newer cmake versions.

By omitting the variable CPM_SOURCE_CACHE as CACHE'd, it is actually
given to CPM, but does not appear when viewing it's content, e.g.,
through ccmake. Mark is as CACHE so that it will also appear.

 - Added CPM fallback in case package is not found automatically.
 - Using yaml-cpp::yaml-cpp target instead of yaml-cpp to silence deprecation
   warnings on newer cmake versions.

Refactor NAS 5GS PDU Session Establishment Accept handling

- Closes #841
- address minor code issues

Add F1 Handover procedures

- Clean up at RRC and MAC
- Add DU handover procedures, completely handle CellGroupConfig at DU
- Add CU handover procedures
- Maintain reestablishment working between/after handover
- Changes at UE to resync on different frequency DUs

Instructions: see doc/handover-tutorial.md

Things not implemented/open/missing: see #855

F1AP Enc/Dec Library follow-up

Follow-up after !2890

Co-authored-by: rmagueta <rmagueta@allbesmart.pt>

When receiving a measurement report including an A3 event, trigger
handover towards the indicated cell.

Note that currently, we are still limited to one Cell by DU, hence
looking up a cell comes down to looking up a DU, as is done here.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: Luis Pereira <lpereira@allbesmart.pt>
Co-authored-by: Robert Schmidt <robert.schmidt@openairinterface.org>

During handover, we might receive a UE context Modification required
message. Currently, we cannot handle this; ignore the message.

This commit implements reestablishment during handover when occurring at
the source DU, either as a handover Failure or "normal" reestablishment
(something else went wrong). In this case, the CU will trigger HO
cancel, which in F1, means to cancel on the target DU. Also, undo any
previous ID changes. Retain the old CellGroupConfig (before handover)
for the case of reestablishment at source. If not needed, it is freed
after the reconfiguration complete.

Reestablishment on target cell during handover cannot be handled by the
gNB (yet). It is the same as with a normal reestablishment (not during
handover) on a different cell: that cell has no notion of the old UE, so
we cannot simply indicate the old UE to reestablish; at least, we would
need to cleanup the CellGroupConfig, and I am not sure this works out of
the box, either.

After handover, the last CellGroupConfig received is the one for
handover, containing a reconfigurationWithSync. Resending this
CellGroupConfig to the UE after reestablishment would trigger a
handover. Free the reconfigurationWithSync to have the UE complete
reestablishment at the current cell.

The CU implementation of reestablishment modifies the CellGroupConfig.
It should not do this, but does as of now. The specification (38.473 Sec
8.7) foresees an optional F1 UE context modification procedure (which
can be used to receive the CellGroupConfig). This should be done instead
to retrieve the correct CellGroupConfig.

Note that the F1 UE context setup procedure, similar to the UE context
modification procedure, would also allow to perform reestablishment on a
DU that is not the original one.

If we release a request from a DU during, handle as follows:

- from the source: Handover is still ongoing, so ignore it by
  acknowledging the release, and marking handover as done. In this case,
  we did not receive an acknowledgement from the target, but since the
  source DU does not keep the UE context, we could not cancel the
  handover anymore either. The UE might come back on any DU through
  reestablishment (or simply be connected on the target)
- from the target: consider this to be a genuine release, and forward to
  AMF.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>

The HO is completed (from a pure RAN perspective) when receiving
reconfiguration complete. In that case, remove the HO context, and
signal successful handover through the callback. For the F1 handover,
this means releasing the UE at the source DU.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>

We expect the UE's RRC Reconfiguration Complete to come through the
target DU, as the "new UE" at the target CU. Also, function
CU_handle_UL_RRC_MESSAGE_TRANSFER() checks that the UL RRC Message,
through which we will receive RRC Reconfiguration Complete, matches the
DU UE ID stored in RRC. Since the DU UE ID will be the one at the target
DU, while up to now, we stored the DU UE ID at the source DU.

Correspondingly, update the DU UE ID to the one at the target DU; also
update the corresponding assoc_id.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>