GitLab

This fixes @danstaines's issue:
[Feb 11th at 09:49]
I've got a problem with hive where I supply a registry, and the registry takes
a couple of minutes to load (this is normal with 40k bacteria unfortunately).

The registry takes a lot of time to load, so the worker is running from the LSF
point-of-view but is not registered in the database yet (because the DBAdaptor
object is not ready yet). Because of the discrepancy, beekeeper thinks that
nothing is running and keep on submitting new workers (beyond the analysis
capacity)

My fix is to basically count those workers as pending. Because the
Valley/Meadow had a method to get the running workers and another one to get
the pending workers, I had to unify them into a single method which saves us
one call to _bjobs_. Then the Valley adjusts the counts into a complex hash
that contains accurate information about all the workers. This super-hash is
then carried around in various places so that all the decisions are consistent
to each other. Overall the Valley now does more things and the Meadows are a
bit shorter

The test-suite has been updated accordingly

bugfix: stop registering some NO_WORK workers as UNKNOWN, by changing the order of Valley/DB reconciliation

Added 'meadow_user' to Worker object+schema which is now routinely recorded. Also renamed 'host' to 'meadow_host' for consistency

finally implemented LSF's version of count_running_workers() and a Valley aggregator for all visible meadows

make Valley into Configurable and move SubmitWorkersMax into Valley's context, because it is more "global" than a Meadow

moved submit_workers_max/pending_adjust/total_workers_max/meadow_options into Config, but they are still configurable from BK's commandline via config_set(); lots of code cleanup on the way

valley now contains available meadow objects, not classes; beekeeper contains corrected algorithm for killing a worker