GitLab

Workers were in fact designed not to update the analysis_stats table too
frequently. The "done_job_count" counter is updated every two minutes.

This reverts commit 258cbf59.

Otherwise, the counter was only updated by the garbage collection process, or
by the hard sync. Before, we could see the issue by doing this:

```
\## in one terminal
init_pipeline.pl Bio::EnsEMBL::Hive::Examples::LongMult::PipeConfig::LongMult_conf -pipeline_url $PIPELINE_URL
\# to have plenty of jobs to test on
for i in `seq 1 50`; do for j in `seq 1 50`; do seed_pipeline.pl -url $PIPELINE_URL -logic_name take_b_apart -input_id "{'a_multiplier' => 2112974${i}29187, 'b_multiplier' => 3273${j}58788}"; done; done
\# loop but don't submit anything
beekeeper.pl -url $PIPELINE_URL -submit_workers_max 0 -loop -sleep 0.05
\## in another terminal
runWorker.pl -url $PIPELINE_URL -analyses_pattern 1
```

In the beekeeper output the counter of done jobs remains 0, and the
in_progress counter keeps on increasing

* version/2.2:
  Set an empty string to avoid a warning
  Updated the installation instructions

* version/2.1:
  Set an empty string to avoid a warning
  Updated the installation instructions

Conflicts:
	docs/install.html
	scripts/db_cmd.pl

* version/2.0:
  Set an empty string to avoid a warning
  Updated the installation instructions

* version/1.9:
  Set an empty string to avoid a warning
  Updated the installation instructions (we e73 is one of the few versions that actually work)

Conflicts:
	docs/install.html

* version/2.2:
  bugfix: allow dashes in database names

Conflicts:
	scripts/db_cmd.pl

* version/2.1:
  bugfix: allow dashes in database names

* version/2.0:
  bugfix: allow dashes in database names

* version/1.9:
  bugfix: allow dashes in database names

* Use File::Glob to get the list of filenames

Previously backtick ls command was used to fetch the list of sql patches filenames.
By using backtick it is required to fork a new process. This would potentially be
a problem for a running process that uses large amount of memory. If there is not
enough spare memory left in the system, the fork operation could be aborted because
of "cannot allocate memory" error.

Fixes ENSEMBL-4823.

[ The PR was added to 2.2 but somehow discarded when 2.2 was merged into 2.3 ]

Conflicts:
	modules/Bio/EnsEMBL/Hive/DBSQL/SqlSchemaAdaptor.pm