the database.

Bug 5247

Previous logic could trigger KNL node reboot when job did not
request any KNL MCDRAM or NUMA modes as features. For example:
srun -N3 -C "[foo*1&bar*2]" hostname
would trigger reboot of all KNL nodes even though no KNL-specific
features were requested. This bug only exists in v18.08 and was
introduced when expanding KNL node feature specification capabilities.

Invoke select_g_job_test() one time with all valid node rather than
multiple times when adding higher weight nodes. This results in
the job allocation always accumulating nodes from lower to higher
weights rather than possibly using mostly higher weight nodes.
It also streamlines the resource allocation process for most
configurations by eliminating some repeated logic as groups
of nodes are added for consideration by the select plugin.

Cleaned up code that could've caused performance issues when reading config
and there was nodes with features defined.

bug4980

fix for commit 4a0a6a94
bug 4821

bug 4821

Add 64-bit sched_weight (scheduling weight) to node_set struct
Populate it with the node's weight (possibly reboot weight)
plus high-order bits for FLEX-reservation and rebooting.
No longer are node weights of INFINITE or (INFINITE-1) used
to flag FLEX or reboot requirements so we don't need to
worry about overlapping node weight values. It also will
cleanly allow the cons_tres plugin to be passed ALL usable
nodes at one time to accumulate resources from the lowest
weight first and only use individual higher weight nodes
as needed (rather than possibly using mostly higher
weight nodes).
bug 4821

breaks out node sets by in/out flex reservation and need to reboot
bug 4821

The node weight of a node requiring reboot is not a fixed value
in v18.08, but configurable
bug 4821

bug 5337

bug 5337

bug 5337

This test change addresses gres api changes introduced in commit
6e0469b5

Implicitly set node count, task count, ntasks_per_* as appropriate

Prior logic lacked a line-feed and ran lines together

Previous logic was implicitly starting 2 tasks due to the combination
of --gpus and --gpus-per-node

Original logic was testing against number of available CPUs on a
node, not the number actually being allocated. This can easily result
in a valid job not being possible to run. Note that setting the
max_cpus parameter requires the "scontrol update jobid=# numcpus=#-#"
command be explicitly executed as the option is not available at
job submit time, so it isn't something likely to happen on a
production system. Also note this bug exists in the cons_res plugin
and was just copied to cons_tres.

When one asks for an inactive feature and also specifies the node with -w flag,
the node will be rebooted despite it may contain running jobs.

bug4821

Return resource array structure rather than just CPU count

and avoid race condition calling task before proctrack can introduce.

Bug 5319

to work correctly.

Bug 5155
Bug 4516

delayed until the first job completes execution and it's burst buffer
stage-out is completed.

Bug 4675

If MailProg is not configured and "/bin/mail" (the default) does
not exist, but "/usr/bin/mail" does exist then use "/usr/bin/mail"
as a default value.