When the number of Fibers is greater than the number of connections to
postgresql in the connection Pool, a race condition occurs when
generating the SQL query as this requires a connection for encoding
context. Indeed the visitor used for Postgresql to generate the SQL from the AST
generated by active_record is not Fiber safe, and will not generate the
proper SQL if used concurrently by multiple Fibers. This will happen as
a connection must be available to escape Strings, and the generation
will hand over control to an other Fiber is none is available.

lib/tasks/tunneling.rake is generated from the puppet recipes

Adapt to the fact that stunnel is no longer configured on api-server-*
machines

This should ease working with a dump of a production database

- deprecate instructions for rvm users, as no active developer maintains them
- refrech text about getting access to a copy of an OAR DB

Use the Grid'5000 fork of em-postgresql-adapter to be able to remove the
warning it generates

This parameter now seems honored, and the development configuration of
mysql does not allow for so many open connections

Bugs/#9337

Make rake tasks to manage the oar database work in the development
environment

The setting made by spec_helper was different from the setting in
rails_helper. Only keep the last

reorganize status code to separate cleanly the different steps of the
algorithm, and to handle all data structures specific to nodes in a
generic way.

This makes it possible to only build the list of
active jobs with their associated resources once
instead of twice.

The updated status class method will take the types
of resources for which a status is required and build
an aggregated hash indexed by type for easy use by
controllers

The implementation is rather crude, using multiple
case statements instead of some form of generic
programming.

Instead of querying asisgned_resources and then gantt_jobs_resources,
build only one query using SQL4s UNION construct

As anonymous users will not see future reservations, exclude waiting
jobs from the query used to understand available resources

They get a forced value of job_details param when calling
sites/<>/status and are not considered authenticated users

Bug7970 status api performance v3