Apparently 5353 is commonly used for mDNS, and so counts as "already in
use" on many consumer machines.

It turns out that the clone-and-hack in tests/chutney/arti-bench
was not identical to the original in tests/chutney/setup.

I diffed the two and preferred the version from arti-bench.

Formerly, the "launch a chutney network" code was duplicated in
"setup" and "arti-bench", since "setup" always launched an arti
proxy, while "arti-bench" didn't want that functionality.

Now the "setup" script launches an arti proxy conditionally,
depending on whether the "proxy" argument is given.

This is not a replacement for a real startup protocol, but it may
help repair our CI.

Now that arti listens immediately, a very short sleep ought to do.

As per #309

Update all references.  There is one remaining hit for
  git-grep '\.sh\b'
namely "build.sh" in maint/reproducible_build, which I think is
the build script for osxcross - ie, an external project.

This adds `arti-bench` to the `integration` job in the CI pipelines, and
keeps around the JSON benchmark output for later comparison.

Rationale: It's good to have all of our scripts pass shellcheck.

Previously, this case would cause arti-bench to hang forever, trying
to bootstrap against one network while another network was running.

(An empty $RUST_LOG no output, and confuse the nickm^Wuser.)

shellcheck doesn't like `export FOO="$(bar)"` as one line, since it
has the possibility of missing errors.

The new `arti-bench` crate does a simple end-to-end benchmark test
embedding Arti: it generates some random data (of configurable amount,
depending on command-line parameters), and then sends said data back and
forth via Arti (which should be configured to use a local Chutney
network).

Additionally, the benchmark can also be run via a local SOCKS5 server
(in order to benchmark the performance via a local Chutney node, for
comparison).

The `tests/chutney/arti-bench.sh` sets up and tears down Chutney as
required to make this work.

This is very much a first cut; there are many things that should
eventually get added, such as support for multiple connections, JSON
output capabilities, running multiple tests, ...

This is per a suggestion from @trinity-1686a.

Previously, if the arti process had died or been killed, we wouldn't
reach the point where we called "chutney stop".

If the user has CHUTNEY_PATH set, respect that value, rather than
cloning a local chutney.

Also, if we have a local chutney, then update it in case there have
been changes.