zodbtools provide additional service over zodb (various dumping
routines), but neotools just invokes neo.NewMaster and neo.NewStorage.

For a possible future `neo monitor` maybe bringing neotools back would
be needed, but for now there is simply no reason to keep them around.

not used outside neonet.

Don't try to play with file.readline() - that seems to be working for
usual cases, but:

1. it does not work for cases when e.g. a dot is printed for every test
   run on the same line (e.g. neo/py tests, pytest, etc...)

2. in case when there is a lot of output available ready to be read it
   would be a waste of resources to read/flush it line by line.

-> use raw OS read with sane semantics.

(fix syntax error there)

We now don't buffer anything inside runTestSuite, but the generating
process itself could buffer e.g. stdout. Tell it not to do so.

if so `hostname --fqdn` errors with

	hostname: Name or service not known

Fall back to just small hostname if there is no fqdn one.

stderr is unbuffered, but by default stdout is buffered, so if stdout in
turn is redirected to be read by some other logging program, due to
buffering output could be delayed.

Don't delay the output.

We send output from tested process to master. We also print it to
stdout,stderr so it appears in testnode logs.

However till now it was like, whole output first read, and only then
emitted to log as a whole, thus not allowing to oversee current test
progress by watching testnode log tail.

Fix it by implementing the teeing process manually and using only
line-buffered mode inside.

Extracted from slapos!282

killall is optional (comes from psmisc package) and besides `killall
runzeo` is not safe as it can be killing not only runzeo spawn from
under neotest, but also from other processes.

-> Switch to explicit kill with runzeo pid.

This is useful for development and just checking ZODB part of the
benchmarks without going first through cpu and disk parts.

run-client renamed to zbench-client for consistency.