Summary of changes:
- free configmodule memory when shutting down
  It is possible to restart the lte-softmodem via the FlexRAN controller.
  For this to work, the end_configmodule() method needs to be called when
  shutting the lte-softmodem down so that the configuration can be read
  again during a restart.
- Feature agent
  Implements an agent ID, consisting of the OAI module ID, the OAI eNB ID
  and the cell ID. The agent reads this information in its configuration
  read function and forwards it to the controller.
  This MR also contains some code forwarding SI info to the controller.
- various bugs fixed
  - remove start_background_system from eNB softmodem
  - fix memory leak when doing traffic
  - disable ITTI dump (does someone uses this?)
  - disable U-plane inactivity timer: it's very simple to put this back,
    but as of now it comes with its own problems that we don't have time
    to check/fix

Only ulsim and dlsim compile. The others (dlsim_tm4 pucchsim prachsim
pdcchsim pbchsim mbmssim) have been disabled.

Command line to compile: ./build_oai --phy_simulators

This is only needed by the UE code, to setup IP settings.
The eNB does not need this. (To be reverted if this is
wrong.)

When doing TCP downlink traffic with iperf for several
hours, the memory consumption of lte-softmodem does not
stop to grow.

After analysis, this commit seems to be the only fix needed.
To be checked somehow.

If anyone needs it, it's a simple matter of reverting this
basic commit.

It is annoying and does not seem to work properly.
To be checked/reworked if needed.

Keep in mind that we also want oaisim to be functional.

if the FlexRAN agent is disabled, do not read all the data and skip reading
of more information

The agent_id is a uint64 consisting of: module ID (i.e. mod_id, the several
instances of OAI at once, 16 bit), the enb_id from the configuration file (32
bit) and the cell_id from the configuration file (16 bit).

The module ID is part of the agent ID but it is easier to have it directly in
the struct.

It is possible to restart the lte-softmodem via the FlexRAN controller. For
this to work, the end_configmodule() method needs to be called when shutting
the lte-softmodem down so that the configuration can be read again during a
restart.

The PHICH was not programmed for the last round (4) because it was
not programmed in rx_sdu but in schedule_ulsch_rnti, only in case
of a programmed retransmission (there is obviously no retransmission
programmed after the last round).

The case of Msg3 is not handled. To be done somehow.

The code is too complex. This commit may not be enough.

Conflicts:
	cmake_targets/build_oai
	common/utils/itti/intertask_interface.c
	openair1/PHY/INIT/lte_init.c
	openair1/PHY/LTE_TRANSPORT/dci.c
	openair1/PHY/LTE_TRANSPORT/dlsch_modulation.c
	openair1/PHY/defs.h
	openair1/SCHED/phy_procedures_lte_eNb.c
	openair2/ENB_APP/enb_paramdef.h
	openair2/LAYER2/MAC/defs.h
	openair2/LAYER2/MAC/eNB_scheduler.c
	targets/ARCH/COMMON/common_lib.c
	targets/COMMON/create_tasks.c
	targets/RT/USER/lte-enb.c
	targets/RT/USER/lte-ru.c
	targets/RT/USER/lte-softmodem.h

Summary of changes:
- bug fix in the FlexRAN API (correct a check)
- bug fix for sending the right RNTI in a FlexRAN message
- fixes small bug in ulsim which kills one RX antenna in channel simulation.
  Another simple but bad bug in ulsch_demodulation.c (bad access of avgU
  array). This probably resulted in a performance degradation for non-ideal
  channels, even for 1 antenna. The avgU was read in position 1 instead of
  0 for 1-antenna and in positions 1 and 2 instead of 0 and 1 for 2-antennas.
- work from Nokia:
    1) shared library loader, with integration for oai devices, encoder and telnet server
    2) telnet server (use build-oai --build-telnetsrv option and --telnetsrv softmodem option)
    3) UE/eNB in different executables (lte-uesoftmodem and lte-softmodem + noS1 variants)
    4) config module fixes and extensions
    5) very preliminary NB-IoT integration preparation, using shared lib loader ( use make NB-IoT to build, after building the eNB softmodem)
    6) Rename NB-IoT configuration sources from nbiot_ to NB-IoT_ to be consistent with other NB-IoT developments.
- various bugs fixed:
  - try to avoid "buffer full" problem when pushing DL traffic
  - add a stop_rf function in the RU
  - cleanup - remove unnecessary calls to get_cpu_freq_GHz
    (was disrupting realtime at startup, generating lots of UU and LL)
  - cleanup MAC PDU generation

Compilation with Rel10 is not functional anymore.
Compilation of unitary simulator is not functional anymore.

End of line character has to be unix-style, not dos-style.

* bug fix in the FlexRAN API (correct a check)
* bug fix for sending the right RNTI in a FlexRAN message

fixes small bug in ulsim which kills one RX antenna in channel simulation.
Another simple but bad bug in ulsch_demodulation.c (bad access of avgU
array). This probably resulted in a performance degradation for non-ideal
channels, even for 1 antenna. The avgU was read in position 1 instead of
0 for 1-antenna and in positions 1 and 2 instead of 0 and 1 for 2-antennas.

Merge remote-tracking branch 'origin/develop-nbiotconf-shlibloader' into develop_integration_2018_w10

1) shared library loader, with integration for oai devices, encoder and telnet server
2) telnet server (use build-oai --build-telnetsrv option and --telnetsrv softmodem option)
3) UE/eNB in different executables (lte-uesoftmodem and lte-softmodem + noS1 variants)
4) config module fixes and extensions
5) very preliminary NB-IoT integration preparation, using shared lib loader ( use make NB-IoT to build, after building the eNB softmodem)
6) Rename NB-IoT configuration sources from nbiot_ to NB-IoT_ to be consistent with other NB-IoT developments.

This is hack-level development.

With this commit you can do UDP DL traffic of say 100Mb/s over
a 5MHz link with one connected UE and the eNB should not crash
because of memory exhaustion. Of course on the receiver side
you won't get 100Mb/s and many many lost packets. But the system
should not crash. 1Gb/s does not work. So in any case try to
remain within some reasonable limits. There is no reason to
push more than twice the maximum achievable throughput of
the link.

This work is based on a patch proposed by Francesco Gringoli.

When the program exits it has to stop the streaming of the USRP.
The function exit_fun is supposed to do that. When quitting with
control+c (very common case) this function is not called. The
code is very unclear there, so let's add a stop_rf in the RU,
as there is already a start_rf.

If we don't call trx_end_func, then at the next run the USRP
device may be in an unstable state and behave improperly.

If the program crashes then the USRP device may be in an
unstable state. The only solution to this problem is to reset
the USRP device.

Maybe there is a way to clean the state of the device when we
open it, before we start using it. Sort of a cleanup before
use. That could be a better solution to "bad state after program
crash".

What has been tested:
- monolithic eNB only

The one in lte-enb.c disrupts the realtime. Using a B200mini with
20MHz bandwidth leads to the UE unable to connect for it seesms like
the UL and DL are not properly time synched because of this sleep
of one second that happens after the USRP streaming has started.
We see some random access attempts but the decoded preamble is
wrong.

This may be dependant on the setup. I had sporadic errors with
a B210, where sometimes the UE could connect and sometimes not.

The code was very unclear and potentially buggy.
This new version is more robust.

We can waste up to 2 bytes because the last header in the MAC PDU
does not contain a length field and when we request data from RLC
we suppose a 3-bytes MAC header. This might be optimized at some
point, but the benefit would be low.

This commit also contains some general cleanup:
- formatting
- variables' types: let's use 'int' instead of trying to be clever
  by using small types that may generate bugs if the value is
  too big
- remove 'tpc_accumulated' which was globally used for all UEs
  and has no purpose other than logging. We may want to rework
  a bit the TPC machinery at some point. As the code is today
  we may repeatedly send TPC over and over without caring about
  the 3GPP limits, in which case no one knows how the UE is
  supposed to behave: does it clamp the current max value or does
  it accumulate over and over and take the clamped value to compute
  its actual power? If we send a reverse TPC (reduce power instead
  of increase) does it do it immediately or does it have to decrease
  n+1 times if we previously ordered it to increase n times?)

We do not address the problem of prioritizing LCIDs. As of today there
is only one dedicated traffic channel (DTCH), so it's not a problem
at this point.

What has been tested:
- monolithic eNB 5/10/20MHz with one cots UE, TCP/UDP UL/DL. At 20MHz the
  machine used was not capable of keeping up, generating lots of Us
  and Ls when the throughput reaches 60Mb/s. USRP B210 was used.