Changes

contrib/*sysmo.sh: Fix default poky SDK version to 2.3.4
Current latest poky SDK is 2.3.4, and that's the one we have installed
in all buildhosts.
Change-Id: I8c855456c7f94a3d6ee58ca550a056a0fea61a71

contrib/*sysmo.sh: Fix default poky SDK path
ansible scripts are installing the SDK in "poky-sdk" dir, not "poky"
one.
Change-Id: I002fde53684cd4a43c9f22e09264056f2a950c24

config: Fix reading empty yaml default-suites.conf
during config.read(), on empty file yaml.safe_load() returns None, which
was then later converted to string "None" by _standardize(), and
osmo-gsm-tester.py was not catching "not combination_strs" condition.
Change-Id: I07d7daab8f8f4238db140f0a0311f3d1d41e6cb0

contrib: Fix default variable value syntax
Change-Id: I23abf33881f64dd89c0bf5ef970972908d337366

contrib: srslte: Allow changing repo name
Change-Id: I06e6566ac3df9369b391bc88f288f72588088ef1

suites/debug: Allow jumping into python debugger
Change-Id: Ia6262299981f1d7ac2d81c22b7b9b007e096259a

iperf3: Fix netns param not used
Change-Id: I2768ec0c6d2cbfc8411382a983e1ba17cb5f097e

srsLTE: Support configuring different RF backends
Before this patch, only virtual RF through ZeroMQ was supported. This
patch allows configuring srsUE and srsENB to use a real SDR with
UHD/SoapySDR backend connected through a physical RF network, while
still keeping compatibility to run on virtual RF ZeroMQ network, based
on the resources used (controlled by scenarios). For instance, one can
first run a suite through the phyisical RF (using 2 UHD-controlled SDRs)
and afterwards with ZeroMQ using the following default-suites.conf:
- 4g:srsenb-rftype-uhd+srsue-rftype-uhd
- 4g:srsenb-rftype-zmq+srsue-rftype-zmq
Change-Id: I7dbbe328f4c0225fe74e878bb2da13fe39ccf049

remote: Fix comment typo
Change-Id: Ie466a95d354dc8c9d6960f713948426dadc58241

srsue: Create netns on demand
Already existing script osmo-gsm-tester_netns_setup.sh is modified to
support only creating the entns without moving an iface to it.
Change-Id: I1b7e186b0146f932fe37fbea68e4dfa3120b7a74

Add test log to junit output
Change-Id: Ieb5566a41ecf3a9512db579eb37e8d8ed5325057

srs_enb: Make num_prb a config parameter
Change-Id: I336e71f53556596050cf3eb55a7810a009dbf7a8

enb: Add modifiers for num_prb
Change-Id: I0b8c834f1c67cc4bf4d07d03358ba2012331cbde

Introduce parametrized scenario files support
The idea is to have something similar to systemd template unit files:
https://fedoramagazine.org/systemd-template-unit-files/
Specially for modifiers, one finds the situation where same scenario
structure has to be created with lots of different values. For instance,
let's say we want to test with different eNodeB num_prb values:
[6, 15, 25, 50, 75,100] Right now we'd need to create one scenario file
for each of them, for instance: mod-enb-nprb6.conf mod-enb-nprb15.conf
mod-enb-nprb25.conf mod-enb-nprb50.conf mod-enb-nprb75.conf
mod-enb-nprb100.conf
And each of them containing something like (changing the num_prb value):
""" modifiers:
enb:
- num_prb: 75
"""
Instead, we can now have one unique file mod-enb-nprb@.conf:
""" modifiers:
enb:
- num_prb: ${param1}
""" The general syntax is: "scenario-name@param1,param2,param3". So "@"
splits between scenario name and parameter list, and "," splits between
parameters.
For instance, one can now run following suite with scenario:
"4g:srsenb-rftype-uhd+srsue-rftype-uhd+mod-enb-nprb@75"
Related: OS#4424 Change-Id: Icfcba15b937225aa4b1f322a8005fcd57db1d1ca

Use parametrized scenario to set ENB num_prb
Change-Id: Iec7d7e6312aee6f4e4ce6710bc78a144beff2f39

Introduce LTE Transmission Mode and RLC DRB mode params
Change-Id: I38f247f266ba736cdbb6f36ba5673b8fd46a8d67