This tracer allows the connection of several tracers to one tracee.

To use the multi tracer:
- run the tracee as usual, eg. ./lte-softmodem -O xxxx.conf --T_stdout 0
- run the multi tracer: ./multi -d ../T_messages.txt
- connect other tracers to the multi tracer:
   - ./enb -d ../T_messages.txt -p 2022
   - ./textlog -d ../T_messages.txt -p 2022
   - etc.

By default the multi tracer connects to the tracee to the port 2021,
as for any other tracer.

Then it accepts connections from other tracers on the port 2022.

This can be changed with parameters on the command line.

The tracee and the other tracers can be stopped/started at any time.

- bug fixed in ue and enb tracer: the socket needs to be closed
  in case of restart
- cleanup: fix spacing in T_messages.txt

Pass the command line arguemnt -vcd to trace all VCD variables
and functions.

- install package 'vim-common' to have 'xxd' needed by the compilation
  process of the T tracer
- change the way xxd is called so that no file is created in case
  of error

remove compilation warnings, especially when disabling T_TRACER. enhance LOG_M macro implementation, introduce LOG_DEBUG_XXX macro to replace #ifdef DEBUG_XXX

log.c simplification, fix usefull functionality which never worked, move all log code from openair2 to common

2. minor modifications in dlsch_demodulation.c for 2 eNB TX antennas, 1 RX antenna. Inconsistant indexing of some arrays in this case.
3. change in config_load_configmodule.c : removed exit(-1) when no configuration file is used. This makes unitary simulators exit. Effect on lte-XXsoftmodem TBC.

This was used for the ITTI analyzer.

The ITTI analyzer is now to be considered obsolete.
The source code will be removed at some point.

Log review step 1: legacy VCD removal, LOG macro modified, TTracer enabled at build time by default, in a way it, by default configuration,  provides console logs, as in previous versions

T tracer configuration identical for all executables, no ref to T Tracer config variables (T_port, T_wait...) outside the T tracer

Remove compilation warnings, also fix telnet server compilation failure and NB-IoT shared lib compilation failure introduced when reviewing L1 sources  organization

Whenever the value T_BUFFER_MAX changes, the tracers had to
be recompiled. The only reason why it was needed is because we
used some fixed size buffers to read events. This commit removes
this restriction.

Also, with the basic simulator, this value T_BUFFER_MAX now comes
with an #ifdef which would have required some special hackish-level
tricks in the tracers, which is not good.

Let's just allocate memory when needed.

This commit introduces a 'basic simulator'.

This basic simulator is made of:
- the standard eNB code using a special driver that mimics the USRP driver
- the standard UE code using a special driver that mimics the USRP driver
- no channel simulation
- some special code to deal with faster-than-realtime behaviour of this
  basic simulator

It connects one UE to one eNB. It requires an EPC, populated with the
correct configuration for the UE.

This is the initial release and may contain bugs (most probably race
conditions due to the faster-than-realtime behaviour).

To use it, see the documentation at:
    targets/ARCH/tcp_bridge/README.tcp_bridge_oai.

It has been tested with 25, 50 and 100 RBs, FDD mode.
(No check at all has been done to know if it could work in TDD mode.)

That allows to run several programs using this mechanism on the
same computer (say both eNB and UE, to debug).

(cherry picked from commit 3432385280c3155ee63a54be7c2e4846a17299de)

# Conflicts:
#	openair2/UTIL/LOG/log.c

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

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.