this bug exists with all select plugins. if a job has been allocated
gres and the gres have either topology or type information and the
slurmctld daemon restarts (while the job is running), then when the
job ends gres underflow errors will be generated. the problem is
due to the slurmctld not having gres topology or type information
available at restart time so that it can not update counters. the
overhead of updating those counters at node registration time is
high, so we just avoid generating the errors in this case.
note: this bug is not specific to cons_tres and  exists in
earlier versions of slurm.

if the step does not explicity specify a gres-per-node value,
then the step will be allocated gres identical to that allocated
to the job

also relocate tres_mc create/destroy location so information can be
access from additional locations and to reduce overhead of creating
it multiple times

it is not going to work in practice

Modify gres_plugin_job_alloc() to allocate pre-selected GRES.
Add fields to job GRES data structure to define selected GRES
before job allocation time.

MySQL permits up to 64-character database names, but Slurm was truncating
at 33-characters. If we exceed this limit, let the mysql_query fail and
give the admin a chance to sort it out, rather than truncating and then
failing to query against the un-truncated name later on.

While here correct the fatal() message.

Bug 5586.

Partial revert of 5b5228d0.

Calling init() on certain plugins is not safe. Remove the option,
documentation, and the test case for this.

See 19fc9d94 and the reversion in 61f04d67 as well.

Bug 3445.

Bug 5554

# Conflicts:
#	testsuite/expect/test1.76

Bug 5584

1. The cpu frequency set by the user is not exact with
   current kernels, but close. This changes the logic accordingly.
2. The original logic would cause the test to hang indefinitely
   if the submitted job never ends. This adds timeout checks
   on the job wait, plus adds a 1 minute time limit on the job.
3. Improve/simplify the parsing logic.

Bug 5584

Currently only valid nextstate states are down and resume/idle so the
node shouldn't be in a drain state after transitioning into either of
these states.

Bug 5544

This also clears up a potential race around ping_thread_cnt
as it was protected by ping_mutex in one location and shutdown_mutex
in another.

- Do not look it up again in the backup controller.
- In the backup controller, stop comparing it at all and instead
  use the backup_idx value to decide if we're outselves.

This is not a valid response here - backup and primary
must always be running the same version, so do not attempt to
handle this here.

There's no point in pinging controllers with a lower priority
than yourself - they'll already be pinging you. As we did nothing
with that data, don't bother to collect it, especially as lower
priority controllers being unavailable will delay the next pass
through this loop.

Reference backup_inx directly after startup, and exit much
earlier if this host is not a valid controller. Return a
non-zero exit code in this situation as well.

Collapse into a single function so we can appropriately warn
if a mix of options are in use.

This also avoids a confusing-looking xmalloc with the count padded by two,
which was being used to build out space for ControlMachine if SlurmctldHost
was not defined. This would have also masked off a series of off-by-one
errors, and has lead to attempts to connect to 0.0.0.0 instead of a segfault.
(Some code was intentionally using this over-provisioning as a way to
treat this as a NULL-terminated list, but this was then technically
incorrect in cases where the old-style BackupController was set since the
NULL would happen at the third position in the array, which is an invalid
memory access.)

And document why these are handled the way they are here.

This results in an out-of-bounds access (if control_machine was not
being intentionally over-alloced to avoid it), the wrong address,
and other subtle problems.

C's order of operations meant this was resolving as:
i = (_backup_index() != -1);
which is either 0 or 1.

Through sheer luck, this still results in the correct answer for the primary
(_backup_index() is -1, and then i = (-1 != -1) is still 0 which is correct),
and first backup controller (_backup_index() is 1, and then i = (1 != -1) is
still 1 which is also correct), but any further backups controllers will end
up with the address of the first backup.