software/ors-amarisoft: enb+ue: Switch to JSON schemas as the primary source of defaults; stop rendering them

JSON schemas for eNB/gNB and UE specify defaults for many parameters and the
software release use those defaults when parameters are not explicitly
specified on the instantiation.

Some primary defaults - for bandwidth and n_antenna DL/UL - were setup in
render-templates and propagated through all places to avoid duplicating them.

Defaults for many other parameters were duplicated in both JSON schemas and in
the code that handles those parameters.

To avoid this duplication we either need to extend render-templates and put
defaults for all the other many parameters there, or just switch to JSON
schemas to be primary source of those defaults, and use the schemas on
instantiation by automatically loading them and extracting defaults for all
parameters from there.

I decided to go the second way because it avoids additional layer of rendering
and the need to keep on remembering not to put raw defaults in the JSON
schemas. Evidently this is the same approach that Rapid CDN is going to take
(see nexedi/slapos!1380 for details).

In this patch we stop rendering JSON schemas and keep their last rendered
result. In the later patches we will handle formed duplication there and go on
to further merge enb and gnb.

UE is handled brutally for now, because it will be much reworked after.

Actually loading JSON schemas is left as TODO as I do not have resources to
implement that now. Still this step is needed as precondition for further
patches. I hope bit of duplication for enb/gnb parameters is ok, given that
they are now centrally maintained and corresponding TODO warning is in place.

Previously RU type was static parameter of particular software - it was
possible to instantiate cells only with selected RU type for particular template.

In MultiRU it will be possible to generally instantiate all kind of cells -
LTE/NR and TDD/FDD all at the same time and each served by a different kind of Radio Unit.

-> Switch RU to be runtime parameter as a preparatory step for that.

There is now only two software releases:

  - ORS (software-ors.cfg), and
  - generic (software.cfg).

ORS behaviour stays the same as before here by patch.

For generic each cell in cell_list now needs to explicitly specify which kind
of RU it wants to use and with which parameters. There are less defaults: for
example which CPRI board and SFP port to use now needs to be explicitly
specified.

Only ORS tests are left for now. The old test{LOPCOMM,M2RU,ANY} did not
exercised any driver-specific functionality and until recently were not run at
all due to '-' in their file name. We remove them for now and we will add tests
for generic in a soon follow-up patch after switching LTE/NR cell type to also
be a runtime parameter.

Backward compatibility:

  * nothing changes for ORS
  * for generic all RU-related parameters are now moved from cell_list to
    cell_list.ru, there are several renames and besides ru_type ru_link_type also
    needs to be specified. Please see new RU-related JSON schemas added into
    ru/ for details. Cell_list itself now also does not provide a default with
    one cell - if no cells are configured no cells are instantiated.

--------

Appendix. Diff for rendered enb.cfg and gnb.cfg before and after this patch:

```
$ ./pythonwitheggs slapos-render-config.py && xdiff -w config/{old,out}
```

```diff
diff --git a/config/old/enb.cfg b/config/out/enb.cfg
index 1b39f7044..89862f1d9 100644
--- a/config/old/enb.cfg
+++ b/config/out/enb.cfg
@@ -6,7 +6,7 @@

   // Radio Units
   rf_driver: {
-      // default-RU 2T2R  (ors)
+      // CELL-RU 2T2R  (sdr)
       name: "sdr",
       args: "dev0=/dev/sdr0",
       rx_antenna:"tx_rx",
@@ -27,7 +27,7 @@
   // LTE cells
   cell_list: [

-    // default  (default-RU)
+    // CELL  (CELL-RU)
     {
       rf_port:      0,
       n_antenna_dl: 2,
@@ -90,11 +90,11 @@
       srs_hopping_bandwidth: 0,
     },

-    drb_config: "default-drb.cfg",
+    drb_config: "CELL-drb.cfg",

     sib_sched_list: [
       {
-        filename: "default-sib23.asn",
+        filename: "CELL-sib23.asn",
         si_periodicity: 16,
       },
     ],
diff --git a/config/old/gnb.cfg b/config/out/gnb.cfg
index 05deb5ada..1df699a22 100644
--- a/config/old/gnb.cfg
+++ b/config/out/gnb.cfg
@@ -6,7 +6,7 @@

   // Radio Units
   rf_driver: {
-      // default-RU 2T2R  (ors)
+      // CELL-RU 2T2R  (sdr)
       name: "sdr",
       args: "dev0=/dev/sdr0",
       rx_antenna:"tx_rx",
@@ -35,7 +35,7 @@
   // NR cells
   nr_cell_list: [

-      // default  (default-RU)
+      // CELL  (CELL-RU)
       {
         rf_port:      0,
         n_antenna_dl: 2,
@@ -136,7 +136,7 @@
           ],
         },

-        drb_config: "default-drb.cfg",
+        drb_config: "CELL-drb.cfg",
       },
   ],
```

Previously rf_mode was static parameter of particular software - it was
possible to instantiate cells only of the mode selected for particular template.

In MultiRU it will be possible to generally instantiate all kind of cells -
LTE/NR and TDD/FDD all at the same time.

-> Switch rf_mode to be runtime parameter as a preparatory step for that.

Software for ORS becomes just software-ors.cfg with software-tdd-ors.cfg
providing backward compatibility proxy as we have many ORS'es currently
deployed with that software-release URL. For other softwares backward
compatibility is not preserved including for software-fdd-ors.cfg because we
practically have very few deployments with those.

To show tdd_ul_dl_config only for TDD we use conditional feature of new JSON-editor.

Backward compatibility: nothing changes for ORS, for everything else rf_mode
now needs to be explicitly set in cell parameters if it is not TDD.

Rendered enb.cfg and gnb.cfg stay the same.

In MultiRU we are going to have generic software with flexible configuration
and many features + ORS software, which wraps the generic part, adds ORS
specific features, and translates simple ORS schema to generic ones.

Let's first move ORS-specific bits to dedicated place as a preparatory step for that:

- add software-ors.cfg . In the future software-ors.cfg will be the entry point
  for ORS mode, but for now it is only a place from where software-ors-* extend from.

- add instance-ors.cfg . We move ORS-specific code from instance.cfg here and
  set it to use instance-ors-enb.jinja2.cfg when instantiating enb/gnb.

- add instance-ors-enb.jinja2.cfg . This pulls ORS-specific code from
  instance-enb.jinja2.cfg + instance-gnb.jinja2.cfg and wraps them with ORS
  context built by instance-ors.cfg

- in the templates the way to see whether it is ORS or not, and if yes, to access
  ORS parameters is changed: now it is always via checking `ors` object, which
  can be either False for non-ORS mode, or dict for ORS mode, and if it is dict
  the keys inside that dict are ORS specific properties, e.g. ors['one-watt'].

  This adjustment is handy to organize ORS mode extension from generic with
  generic setting `json ors false` in the context, and ORS mode undoing that and
  setting ORS context properly. I think the code also reads more clear this way, i.e. with

 	{%- if one_watt == "True" %}

  changed to

	{%- if ors['one-watt'] %}

  because in the second variant it is clear that one-watt is a property of ORS.

The rendered configs for enb.cfg and gnb.cfg stay unchanged.

/cc @jhuge, @lu.xu, @tomo, @xavier_thompson, @Daetalus
/proposed-for-review-on nexedi/slapos!1522
/reviewed-by TrustMe