The next commit moves the UE Capability Enquiry after the first
reconfiguration. This has the effect that for some UEs (e.g., iPhone),
the Setup Requests come too close to each other, triggering RRC
Reconfigurations while previous transactions are ongoing.

I think the "true" solution would be to implement some tracking of
transactions across RRC, F1AP, E1AP, but this might require many
changes. For the moment, limit to delaying PDU session resource setups
to prevent above problem. Delaying is done using ITTI timers (to be able
to serve other UEs), waiting 10ms each time, up to 20 times (to not
deadlock the transaction -- after all, if the UE is unhappy, it will
drop the connection).

- Put consistently transaction IDs
- Remove transaction IDs when transaction finished, or in places that do
  not trigger an RRC transaction

This commit allows the gNB to handle PDU sessions that the core requests
to setup during the NGAP Initial UE Context Setup. Previously, we only
managed them as part of PDU Session Resource Setup Request.

The RRC will, depending on whether a PDU session is in the NGAP Initial
UE Context Setup, either directly trigger the Security Command, or first
do a bearer setup at the CU-UP. Some asserts have been lifted, as now
the PDU sessions might be present before the RRC Connection is fully
established.

Implement the correct forwarding of the bearers in an F1 UE Context
Setup Request message.

This solves bug #672.

Prior to this commit, the handling of DRBs is complex: first the RRC
"guessed" a DRB ID when setting up DRBs via E1AP (in
rrc_gNB_process_NGAP_PDUSESSION_SETUP_REQ()), and later chose one for
real in fill_DRB_Configlist() (called in
rrc_gNB_generate_dedicatedRRCReconfiguration()).

To simplify, remove fill_DRB_Configlist(), and instead allocate the DRB
using generateDRB() before sending the message via E1AP, in
rrc_gNB_generate_dedicatedRRCReconfiguration(). The rest of the logic is
the same.

For PDU sessions, always mark PDU sessions as "done" to match pdu
session state logic.

It might happen that a UE has no CU-UP (e.g., never requested a PDU
session). When triggering a release, we previously and implicitly
associated a CU-UP in that case. That is not good, and confusing.

This commit adds a function to look up if the UE has an associated
CU-UP. We only send a release if it is the case.

The function get_existing_cuup_for_ue() now instead verifies that a
CU-UP exist, and does not implicitly create an association (which might
be unwanted, see above).

The number of tunnels corresponds to number of DRBs, so correctly
compare tunnels and DRBs.

The function rrc_gNB_process_RRCReconfigurationComplete() does almost
nothing, we can delete it.

The variable name ue_reconfiguration_after_reestablishment_counter is
misleading, as it counts all reconfigurations; rename to make it clear.

The drb_active array keeps track of active DRBs. However, it only
replicates some of the information in established_drbs, and could lead
to a reuse of DRB IDs when two bearers are to be set up. Consider the
following:
1. trigger first DRB creation at RRC
2. DRB ID chosen from free drb_active entry
3. trigger second DRB creation at RRC
   -> The first reconfiguration has not been acknowledged
   -> drb_active is not marked as DRB_ACTIVE
4. The second DRB ID is chosen from a free drb_active entry, which is
   the same as in 2.

By reusing established_drbs everywhere, this cannot happen, as we
1. select the DRB to be used using next_available_drb() and then
2. use generateDRB(), which marks the DRB used
all from within fill_DRB_configList, which gives a new DRB.

The logic is still overly complex, though.

If there are no active bearers, the function previously returned an
empty list. Return NULL if there are no bearers, so it is safe to call
this function even when no bearers are present. We can also pass it
every time to do_RRCReconfiguration(), which will not add an empty list
for DRBs.

Create a single function to activate an SRB. This function derives the
corresponding keys, triggers the setup in PDCP, and marks the SRB as set
up, instead of doing all of this common functionality in individual
steps.  Use it at the corresponding places.

- show MAC bytes in one line
- add MCS table idx
- show ulsch errors before ulsch DTX (as in DL)
- show if UE in-sync/out-of-sync
- show CU UE ID next to RNTI to stats

Since we modify the format of the statistics, fix the format in the retx
checkers of the CI.

Only fill the 5G-S-TMSI if if is present, and set the bit in the
presenceMask.

This commit implements retrieval of 5G-S-TMSI from Parts 1&2, or the
entire 5G-S-TMSI, depending on what the UE sends. Further, if it has
been retrieved, print a log of all constituent parts of it.

The UE-specific variable ng_5G_S_TMSI_Part2 is not needed, as we compute
the full 5G-S-TMSI as soon as we have Part2 (and 1).

The correct forwarding to the core is implemented in the following
commit.

We did not give a cause value, and therefore NGAP's "PDU sessions
failed" encoding failed. Give a cause value in all cases, so that this
cannot happen anymore.

To prevent against this, put an AssertFatal() into the encoder that
stops if an internally sent message does not have a correct cause value
(we can at least select a default).

Print an info message for all failed PDU sessions.

In rrc_gNB_send_NGAP_INITIAL_CONTEXT_SETUP_RESP(): if a PDU session is
already established, don't count it as failed.

In all these cases, we simply continue with processing; it therefore
seems that these are more warnings than errors.

- Demote logs judged unimportant to debug
- Indicate UE for UL failure
- set_QoSConfig(): correct log

If we are in one of these procedures, we basically must be in SA mode,
everything else is illogical. It also does not seem plausible to check
for this, as it is not apparent why only these couple of calls should
not be executed if not in SA. Hence, remove.

This implementation might work, but it simply triggers RRC setup on the new
DU when we might send a RRC reestablishment speeding up the whole
connection setup. For this:

- we should send the F1 UE context setup to the new DU
- we should still do the reestablishment, containing the reestablishment message

The latter should be sent once we received the F1 UE context setup
response. We don't need a new context. send a release to the old DU (and
don't release our own context!!).

We might also send the reestablishment to the UE encapsulated with the
F1 UE context setup response. Need to investigate if this is feasible
(because if the DU rejects [can that happen here?], the UE will still
send reestablishment complete -- what then?).

Also, we would need to send the E1 bearer context modification to the
CU-UP.