kernel.

Make it possible to specify the desired threshold before a requests gets saved to a temporary file instead of being read completely into memory.

@nexedi, tests do pass (I squashed commits) so unless objections today I merge it tomorrow.

https://nexedi.erp5.net/test_result_module/20180216-696E64EA

/reviewed-on nexedi/slapos!290

Current version of wendelin.core is limited in that there's no cooperation
in memory allocation between several processes sharing the same /dev/shm.
Over time, the distribution of memory among processes becomes more and more
inequal until some of them get killed due to allocation failure.

This is a temporary solution that relies on user namespaces.

This moves most of the wrapper recipe to GenericBaseRecipe so that
createWrapper automatically switches to Python scripts for complex cases.

Recipes should not use slapos.recipe.librecipe.execute.generic_exec directly
anymore.

It was used in only 2 places and createPythonScript has no equivalent
(maybe reusing 'initialization' from easy_install would produce something
readable enough). For the moment, let's drop this parameter, so that
createWrapper can switch to Python wrappers for complex cases.

There was an inconsistency between the 2 ways of creating executable wrappers:
- createWrapper: parameters-extra defaults to False
- slapos.recipe.librecipe.execute.generic_exec: no option, enabled

An option for that is not worth the effort.
Let's always enable even if it's meaningless.

/software/ and /stack/ will be cleaned up once a new version of this egg
is released.

The workaround for shebang size limitation is removed because it's redundant
with what is done by zc.buildout.easy_install and slapos.recipe.cmmi. This also
fix the issue that a process has a bad name even when the workaround is useless.

kumofs is even abandonned software.

Allow to Add CPU or RAM in hotplug mode, without need of restart qemu process

Remove old and non used debian images, use debian9 image by default now

Fixes MDEV-14799 .

Update go19 and go18 to their latest upstream versions bringing up bug and
security fixes.

Go19 tested briefly on neotest run.

/reviewed-by TrustMe

Using the approach from !258 I checked that all dependencies was pinned down.

Some eggs where not pinned, all git repositories seems to be pinned ( I found there was only `[nginx-push-stream-module]`)

/reviewed-on !269

Tests do pass

https://nexedi.erp5.net/test_result_module/20180205-62704D70

(we can ignore git's hash in tests as I just rebased)

/reviewed-on !285

neotest: Actually add instance and teach it to run `neotest bench-local` under Nexedi testing infrastructure

Commit 31fe231f (neotest: Draft software-release to run NEO/go & friends
tests/benchmarks under webrunner) added "neotest" software release, but
there it added only software supplying - not instantiation - this way
allowing only manual play with neotest.

Recently @rafael approached me saying that one of my webrunner is red on
monitoring because "neotest" software inside fails to instantiate, and
suggested to create a simple instance with bin/runTestSuite inside, so
that this way neotest could be added to a testnode and run on regular
basis by our testing infrastructure.

So here it goes - simple instance with only bin/runTestSuite which tries
to adhere to testnode protocol.

Fixups discovered to be needed while running on testnodes are also included in this merge request.

/reviewed-on !282

lsblk is needed for neotest. Please see details in individual commit messages.

/cc @kazuhiko 
/reviewed-on !283

Similarly to coreutils we need recent util-linux because if e.g. a testnode has
old version of it its lsblk does not work to what neotest expects, e.g.:

	lsblk: unknown column: REV,SIZE

For example we need realpath and if base os provides only older coreutils there
is no such utility and neotest fails:

/srv/slapgrid/slappart8/srv/testnode/bct/soft/55158b6a5b027aa40954c3f974d5b3e9/go.work/src/lab.nexedi.com/kirr/neo/go/neo/t/neotest: line 589: realpath: command not found

Fix it by building & hooking into $PATH coreutils by ourselves.

neotest: Actually add instance and teach it to run `neotest bench-local` under Nexedi testing infrastructure

Commit 31fe231f (neotest: Draft software-release to run NEO/go & friends
tests/benchmarks under webrunner) added "neotest" software release, but
there it added only software supplying - not instantiation - this way
allowing only manual play with neotest.

Recently @rafael approached me saying that one of my webrunner is red on
monitoring because "neotest" software inside fails to instantiate, and
suggested to create a simple instance with bin/runTestSuite inside, so
that this way neotest could be added to a testnode and run on regular
basis by our testing infrastructure.

So here it goes - simple instance with only bin/runTestSuite which tries
to adhere to testnode protocol.

For the actual runTestSuite program I followed the same approach as for
bin/neotest itself - the main program is not processed via any templates
and is used as it was pristinely downloaded, and all buildout
integration is done via first sourcing $SR/neotest-env.sh .
So bin/runTestSuite inside instance follows this approach.

erp5.util is updated from 0.4.49 to latest 0.4.50 because there were
backward-incompatible changes in 0.4.50 release (2 @luke: which btw will
render neoppod and build-rina runTestSuite(s) broken when they try to
upgrade) and for me it would be a waste of time to later go through
updating for 0.4.49 -> 0.4.50 API change, so I used the latest release
right from start.

/cc @Tyagov
/see also kirr/neo@526491d3