along with the dependdencies.
This should also allow us to do away with pip_install as a pre-build
step (and get rid of the associated shenanigans).

…The only

reason to do this was "make mocks" which bypassed bazel. Bazel is bypassed
no-more.

scion.sh was still using togen.py, topodot.py and set_ipv6_addr.py
directly; with the consequence that any significant deviation between the
python environment in the build tree and that of the global environment could
cause these tools to fail.

Instead, we now produce py_binaries for these three tools, install them in
bin/, and use them from there.

To make them work when not invoked from bazel, we have to package them as self
contained executables, which is achieved by adding the --build_python_zip
command line flag. Suprisingly, this is the only method available. There isn't
even an equivalent parameter to the py_binary rule. All other workarounds turn
out to do crazy things (e.g. pkg_tar with the "include_run_files" option
produces non-sense). The tools are requested as part of make all.

Another case of calling python scripts outside bazel was
router_benchmark/benchmark.py. For that one, I arranged so it can be invoked
through bazel (like its twin brother test.py) instead of only from the command
line.

For some very mysterious reasons, flake8 gets broken by build_python_zip.
I have never been able to find how exactly flake8 is made as a py binary
because its creations is mediated by 6 layers of bazel code generation. But
it is indeed made during the build.

If I turn build_python_zip ON for the "build" config only, then flake8 is still
broken, but if I turn it ON everywhere except for the "test:lint" config,
then flake8 works. That makes no sense to me, but I'll be content with that.
Life is short and I am sick of spending mine trying to deconstruct bazel
and python frivolous and broken magic.

…d is not

needed.

Deal with more bazel/python non-sense. py_binary cannot be made with an
imported entry point. There has to be a redundant local wrapper.

…nary.