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>

In this commit, handle the reception of a UE context setup response, in
the case of handover. In that case, store the gNB-DU UE ID and C-RNTI of
the UE at the target DU, and trigger a reconfiguration towards the UE at
the source DU via the callback.

To ensure that the CU-UP's PDCP is SN-aligned with the UE, use
cuup_notify_reestablishment() to reset the bearers with PDCP
reestablishment, which has already been implemented in the last commit.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>

This is preparatory work to handle the UE context setup response from
the target DU. There are two cases:

- "Initial" UE context setup response (during connection setup): we need
  to inform the CU-UP via an E1 message of the new bearers (GTP tunnel
  update)
- F1 handover:  we need to inform the CU-UP via an E1 message that there
  are DRBs to reestablish

There are two different functions, e1_send_bearer_updates() and
cuup_notify_reestablishment(), to do this. Harmonize the code, before
implementing the actual handover logic in the next commit.

Add a function to trigger an F1 handover, including the corresponding
telnet function implementation. The function looks up source&target DU,
creates a HO context, and reads PDU information to send a UE context
setup request to the target DU towards which to handover.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>

Functions get_qos_char_from_qos_flow_param() and
get_qos_characteristics() will be used in rrc_gNB_mobility.c to read PDU
information for handover. Move the definitions to a header to reuse
later.

HandoverPreparationInformation will be used in the follow-up commit to
trigger a handover.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>

This F1 message sends us the CellGroupConfig of the UE. Store it in case
we need it. For instance, at least in OAI, it is possible to make a
handover without a DRB (this might or might not be standard compliant).
However, in this case, we did never receive a UE context setup request,
which stores the CellGroupConfig. Hence, store the first CellGroupConfig
we receive, to be able to do e.g., handover.

RETURN_IF_INVALID_ASSOC_ID() checks if an assoc_id (of a DU) is valid.
It will be also used in the mobility RRC module later. Move it to the DU
header (where it logically belongs) to move it from there.

Co-authored-by: Luis Pereira <lpereira@allbesmart.pt>

Prior to this commit, after RA failure, the DU would send a UE context
release complete, without actually requesting one. This could lead to
inconsistent state between DU and CU, because the CU might just discard
this (unrequested) message, and not actually trigger a release [1].

Thus, refactor the release request into a function, and use it to
request release of a UE for which RA has not been completed. If the CU
does not know the UE, release the UE immediately.

[1] One possibility would be that during reestablishment, the CU would
request to look up an old DU UE ID when it has been released, resulting
in

    Assertion (oldUE) failed!
    In dl_rrc_message_transfer() /home/oaicicd/robert/openairinterface5g/openair2/LAYER2/NR_MAC_gNB/mac_rrc_dl_handler.c:860
    CU claims we should know UE bc7f, but we don't

In handover, we might need to remove a UE that we knew under it's
C-RNTI, for which we also have the RA process. Hence, when removing a UE
by RNTI, remove it also from RA.

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

Improve synchronization to also handle handover between gNB-DUs with
differing carrier freqs.

* DL NAS Transport messages can piggy-back 5GSM messages
* the relevant decoding functions can be called in the handler (e.g. capture_pdu_session_establishment_accept_msg)

Fix scoping issues for variable declarations in switch-case blocks (capture_pdu_session_establishment_accept_msg)

Use capture_pdu_session_establishment_accept_msg with NAS_DOWNLINK_DATA_IND:FGS_PDU_SESSION_ESTABLISHMENT_ACC

* the capture_pdu_session_establishment_accept_msg function is already handling
  the code in the case FGS_PDU_SESSION_ESTABLISHMENT_ACC of NAS_DOWNLINK_DATA_IND

Closes: #841

* take 3 bits for PDU session type value
* add define for SMF's IPv6 link local address

getopt() returns int

Bugfix in ue pusch mac pdu creation

When more than one sdu with equal priority is present, there could be
buffer left after serving the lcids and also not enough to equally serve
all lcids. This commit checks for this condition. Before this fix the ue
would send malformed mac pdus when serving multiple lcids.

See getopt(3): returns int, so store it in an int variable.
I went through all occurrences, project-wide. All return values of
getopt() should be stored in ints now.