Fix SRB_configList2 and DRB_configList2 array position (new_xid) while creating RRCReconfiguration message after RRCReestablishmentComplete

Fixed a bug where the integrity protection was included in the ASN1 and caused significant throughput bottleneck.

Cosmetic changes, also changed the LOG message for updating the UEid, and moved the drb_id_to_setup_start and nb_drb_to_setup right before the function that they are used

Removed the unused variables, and changed the tenary operator conditions of drb_id_to_setup_start & nb_drb_to_setup, to the correct ones

Changed the SRB2 and DRB at the do_RRCReconfiguration arguments, to pass the correct structures that are generated

Simplify RRCReestablishmentComplete procedure with respective function,
removed the block that creates the SRB2  and created a function, with doxygen

Simplify RRCReestablishmentComplete procedure with respective function,
removed the block that creates the ASN1 DRBs  and created a function, with doxygen

Simplify RRCReestablishmentComplete procedure with respective function,
removed the block that updates NGU Tunnels and created a function, with doxygen

Simplify RRCReestablishmentComplete procedure with respective function,
removed the block that updates NAS PDUSession and created a function, with doxygen

Simplify RRCReestablishmentComplete procedure with respective function,
removed the block that frees all the NAS PDUs and created a function for this.

Cosmetic changes, added doxygen configuration, and changed the rrc_gNB_process_RRCReestablishmentComplete function arguments' alignment, so in the future if an argument is removed or added to be better visible in the commits

The generateDRB function now creates a DRB and puts it in the struct member of gNB_RRC_UE_t, from this struct we can generate ASN1 messages by calling the generateDRB_ASN1

Added function to create ASN1 DRB-ToAddMod structs from, gNB_RRC_UE_t established_drbs

Added struct member to gNB_RRC_UE_t to store the established DRBs for a UE, this can be used to generate ASN1 structs, during RRCReconfiguration

integration_2023_w13

See merge request oai/openairinterface5g!2037

* !1945 Free RNTI related structures at PHY after UE disconnection
* !2011 Creation of new pipeline LTE-TDD-2x2-container
* !1854 Handle reconfigurationWithSync
* !2019 bugfix: LDPC decoding in the gNB: clear d properly
* !2038 Fix DL 2x2 errors
* !2039 Adding test-case in XML to reset USRP in LTE-TDD pipeline
* !2008 Implement NR-UE Deregistration procedure
* !2023 Rework PDCP OAI API to allow custom SRB data forwarding (e.g., in F1)
* !2015 Update documentation: CI, general README.md, overview of doc README, various improvements

The GTP module is common for 4G and 5G. It hardcodes the functions to
call when creating S1U and NGU tunnels. The S1U case is both applicable
for LTE and NR (NSA), which until now was not a problem as the PDCP data
forwarding functions where called pdcp_data_req. The issue is that in this
branch, the NR PDCP functions have changed to nr_pdcp_data_req_drb().

When setting up a GTP tunnel, we now pass the PDCP data forwarding
functions into GTP, since the caller knows whether it is in 4G or 5G,
but GTP itself does not.

Merge remote-tracking branch 'origin/develop-handle-reconfigurationWithSync' into integration_2023_w13