To run tapsplit we use plone.recipe.command with both command and
update-command set to `tapsplit ...`. But tapsplit, when run, fully
recreates and reinitializes subtap interfaces, which leads to
interfering with running enb because subtap interfaces, that enb
started to use, are removed. This is not desirable behaviour.

What we need:

1) create subtap interfaces only once and keep them stable
2) until configuration changes which should lead to
   * subtaps recreated, and
   * enb restarted

Carefully reading plone.recipe.command documentation shows:

  command
    Command to run when the buildout part is installed.

  update-command
    Command to run when the buildout part is updated. This happens when
    buildout is run BUT THE CONFIGURATION FOR THIS BUILDOUT PART HAS NOT
    CHANGED.

  (emphasis mine)

So the fix looks to be to make update-command noop - this fulfills
requirement "1". For "2" - I've verified that when configuration
changes, e.g. number of RU changes, buildout reinstalls [vtap] section
from scratch, and it also should restart enb, because generated enb.cfg
changes.

So the fix is fully correct because it satifies all needed requirements.

Dnsmasq insists on dhcp-range's prefixlen to be at most 64, which
triggers the following error if original slaptap is wider than that:

    dnsmasq: prefix length must be at least 64 at line 5 of /srv/slapgrid/slappart6/etc/dnsmasq.cfg

-> Fix it by capping provided range to /64

/reported-by @lu.xu

After escaping strings with dumps (to avoid buildout breakage and code
injection on "tricky" references, e.g. with spaces), promises started to be
generated with !py! prefix in their filenames, e.g. as

    '!py!'\''RU1-sdr-busy.py'\'''

instead of just

    RU1-sdr-busy.py

The issue here is that our code set

    name = !py!'RU1-sdr-busy.py'

and then monitor-promise-base from stack/monitor does

    output = ${directory:plugins}/${:name}

which, I though, would be expanded to .../etc/plugin/RU1-sdr-busy.py but it did
not deserialized the :name upon expansion.

I feel like it is maybe a bug in nexedi/slapos.buildout@4e13dcb9 , but I'm not sure.

Anyway, workaround the problem by generating :output ourselve also via escaped way.

urlparse does not handle raw IPv6 address the way I though it does - extracted
hostname is not the whole address, but only the first part of it:

    In [3]: urllib.parse.urlparse('z://2a11:9ac1:6::5')
    Out[3]: ParseResult(scheme='z', netloc='2a11:9ac1:6::5', path='', params='', query='', fragment='')

    In [4]: _.hostname
    Out[4]: '2a11'

Tests did not noticed this because previouslt we had e.g 4321::1 in the
address, and netaddr thinks 4321 is valid ipv4 address:

    In [6]: netaddr.IPAddress('4321')
    Out[6]: IPAddress('0.0.16.225')

However changing IPv6 addresses to use hex letter trigger the bug with e.g.

       raise AddrFormatError('failed to detect a valid IP ' \
    netaddr.core.AddrFormatError: failed to detect a valid IP address from '2a11'

-> Fix it by avoiding urlparse and doing ip/port splitting ourselves by hand.

/reported-by @lu.xu

when serving symlinks via raw, lab returns link content (= readlink),
not content of the target.

Else enb treats args="" unset and implicitly uses /dev/sdr0 by default.

We do not want implicit default behaviour -> we want to see an error.

In 536b892c I've made a thinko: the documentation on Amarisoft says(*) that
if those parameters are not given, their values are taken from the
"serving cell". With that and after reading https://www.telecomhall.net/t/changing-allowedmeasbandwidth/13045,
especially https://www.telecomhall.net/t/changing-allowedmeasbandwidth/13045/5 I've
made the conclusion that if allowed_meas_bandwidth, and similarly
antenna_port_1, are not provided, they will be extracted by UE from MIB
of that peer serving cell.

But I was wrong as eNB does not start if allowed_meas_bandwidth is not
given for eautra-kind handover in NR cell.

So after checking things in 36.331 we see that:

allowed_meas_bandwidth is optional only in SIB3 (Intra Frequency Cell
Reselection), but in SIB5 (Inter Frequency Neighbour Cell) it is
mandatory, and that is the reason for why enb was complaining about that
missing for NR->LTE handover.

-> restore allowed_meas_bandwidth and antenna_port_1 in HO config.

For intra-eNB HO things are clear, but for inter-eNB HO use conservative
values and put a TODO for considering to extend peer/cell/lte schema
with .allowed_meas_bandwidth and .antenna_port_1 . I think keeping the
schemas minimal is better for now until we really need to do inter-RAT
HO in practice.

(*) https://tech-academy.amarisoft.com/lteenb.doc#prop.ncell_list.allowed_meas_bandwidth

* master:
  recipe/check_parameter: support multi lines values
  software/erp5/test: use short partition references
  stack/erp5: rename an internal parameter still mentioning apache

This reverts commit 5a45624b.