Previously, filling of F1 Setup Request depended on reading the RRC;
hence, for timing reasons, we only initialized and sent the F1 Setup
Request once the MAC and RRC are ready.

After moving SCC, SCD, MIB, and SIB1 to MAC, the MAC does not depend on
an RRC being present anymore, and hence, the F1 Setup Request does
neither. In this commit, we read the F1 Setup Request after initializing
the MAC.

The SystemInformationBlock 1 is handled at the DU and sent to the CU in
the F1 Setup Request. Hence, move it down to the MAC.

The MasterInformationBlock is handled at the DU and sent to the CU in
the F1 Setup Response. Hence, move it down to the MAC. Furthermore:

- Change type because MIB_PDU_t is 4G type
- Simplify schedule_nr_mib()

As with the ServingCellConfigCommon, the ServingCellConfigDedicated is a
radio-related structure to be handled at the DU.

Note: the reestablishment is broken, and a later commit fixes it.

The ServingCellConfigCommon is an inherently radio-related
configuration. As such, it should be handled by the DU, not the CU.
Therefore, move it "down" to the MAC.

The PCI is given to the CU from the DU in the F1 Setup Request message.
It is a part of the DU, so move it "down".

The F1 Setup Response contains the cell(s) to activate. Hence, prevent
the radio from starting by waiting for the F1 Setup Response before
continuing.

- send F1 Setup using callback
- store f1 setup req locally for reference
- check F1 Setup Req against RRC data structures:
  * if matches: send F1 Setup Response using callback
  * if not matching: send F1 Setup Failure using callback
- don't send CU config update by default, we don't need this
- if the Setup Response does not contain a cell, don't activate. It is
  possible the CU sends a gNB-CU configuration update, which will
  initialize the structures

Use a struct to initialize the RRC at the beginning, and remove the
NRRRC_CONFIGURATION_REQ. This message is not necessary; the RRC/CU
should be initialized from the F1 Setup Request, coming from the DU.

Before this commit, we did not read the ServingCellConfigCommon (SCC)
completely at start; rather, we read most (but not all) of it, then also
the minRXTXTIME, and at RRC initialization in
openair_rrc_gNB_configuration(), we filled the
pusch-TimeDomainAllocationList into the SCC, depending on the
minRXTXTIME.

The reason might be that we read part of the SCC, use that to fill the
NRRRC_CONFIGURATION_REQ, read also the minRXTXTIME (part of the RRC
config), and then we have all we need to "finalize the SCC". Since we
move everything to the MAC, I avoid too much upfront code changes,
hardcode the minRXTXTIME (and check with an assert), and undo this in a
later commit when the "RRC config" relevant for radio parameters, e.g.,
minRXTXTIME, is moved to MAC.

I verified the equality of the SCC before (at the end
openair_rrc_gNB_configuration()) and after (at the end of
get_scc_config()) this commit manually using a printf, assuming that
after RRC initialization, we didn't do any further modifications to the
SCC.  But in fact, I cannot know that we don't do it...

- Simplify code by reading the SCC in a separate function
- Fill the F1 Setup Request message correctly in case of FDD, from SCC

This branch series implements the usage of the F1 Setup Request
internally at the gNB, even if CU and DU run in the same process. Until
now, the F1 Setup Request contained struct fields to pass IP
configuration to the F1AP module; this information is not necessary in
monolithic, nor should it be relevant when passing the information in
F1 Setup Request.

Therefore, this commit moves all IP connection-related information out
of the F1 Setup Request and into a separate structure instead.  In order
to give the F1AP module the necessary connection information, the
DU_REGISTER_REQ message is introduced that combines the F1 Setup Request
and IP configuration, such that the F1AP module can setup the SCTP
connection and then send the F1 Setup Request message.

In a later commit, there will be a callback for F1 Setup Request at MAC
to simply register the DU at the CU. The monolithic callback will simply
forward the F1 Setup Request The F1AP callback will look up the IP
configuration and create DU_REGISTER_REQ message containing IP
configuration and F1 Setup Request, which is then handled by the F1AP
module. To this end, a separate function in gnb_config.c allows to read
IP information from configuration.

Instead of storing the F1 Setup Request implicitly in F1 context, we
provide the F1 Setup Request message to be encoded explicitly to the
encoding function.

We ever only have one instance, so hard code that.