The T has 2 processes: the tracee and the local tracer
if the tracee dies (segfault or whatever) the tracee
may still be running.

So there is a third process that monitors those two others
and kill everything when one dies.

The problem is that this third process has to be the parent
of the two others. That makes debugging the tracee with gdb
impossible. This new option disables the third monitor process.

we have to free memory in any case...

git status was way too noisy

ctrl+c did not work when the program was not connected yet.
It also didn't work if no event was received.

And it's sent at each connection attempt.
Before it was sent only once to the first tracer.
Plus there was a bug (length:(len) should have been length:(send_size)).

needed because of the following commit

stuff put in there is of lower quality / coding standard / whatever
and serves as example to do quick debugging taks using the T
infrastructure

the current version is very specific to PUSCH IQ data, where the
input buffer has a special format

to be rewritten cleanly at some point

XY_LOOP_MODE: replace old points with new ones, using the maximum size
              of the view
XY_FORCE_MODE: append_forced sets those and only those points
               and we crash if we pass too much points

to be used in conjunction with another tracer
so conceptually it's more a tracee than a tracer

The distinction common space/user space still requires some
careful examination.

T

I did some compilation tests using `./build_oai -s --run-group "0101*"`, all was fine.

I ran `lte-softmodem` with the sequans and let it run for a while with both
uplink and downlink UDP low throughput traffic, all was fine.

I ran some TCP tests, downlink 14 Mb/s (because the sequans does not report
a CQI of 15 but 14 maximum, so we don't go to maximum MCS, so 14 Mb/s instead
of 16) with a very clean radio (almost no error in the HARQ processes).

For uplink things are not so clean, it starts at 6 Mb/s and after a while goes
down to 2/3 Mbit/s. Lot's of errors in the HARQ processes, mostly uplink but
also downlink.

This is a both with and without T activated.

So to me it's fine.

The T tracer is a debugging tool. When it's not enabled,
it has zero impact on the processing. I think we need to
do very little tests before merging. I'll let you decide
but to me it's okay!

See merge request !36

if you compile *without* T it fails because the T macro is interpreted
as a function call

Conflicts:
	cmake_targets/CMakeLists.txt
	cmake_targets/build_oai
	openair1/PHY/LTE_TRANSPORT/pucch.c
	openair1/SCHED/phy_procedures_lte_eNb.c
	openair2/LAYER2/MAC/eNB_scheduler_ulsch.c
	targets/RT/USER/lte-softmodem.c

very basic, to be refined, find a nice way to display (plot? text?)
protocol data movement