Without this, the record of gres allocated to steps will remain
allocated and not be available to job steps after being requeued.

sched/backfill - If job started with infinite time limit, set its end_time
one year in the future. Previous logic would based it upon INFINITE and
produce an overflow of the uint32_t time.

Report correct CPU count allocated to job when allocated whole node even if
not using all CPUs.
bug 909

Fix bug which could report to squeue the wrong partition for a running job
that is submitted to multiple partitions.

you could get multiple '*' wckeys.

deleting users.

able to be destroyed for debug.

sched/backfill: Correct job start time estimate with advanced reservations.
Under some conditions, the job start time would be set to the end time
of an advanced reservation that may have nothing to do with that job's
resource requirements.
bug 911

file.

If we don't it could get messed up on a reconfig.

Logic used to identify cores which are usable with each GRES weas incorrect.
bug 905

QOS had a GrpNodes set.

Fix for core-based advanced reservations where the distribution of cores
across nodes is not even. Failing test case:
system has 10 nodes, 1 of which is fully occupied
create reservation with 9 nodes and 10 cores
always would fail with "busy nodes" error

errno before each call to the API.

Correct Shared field in job state information seen by scontrol, sview, etc.

allocation and CR_PACK_NODES is set layout tasks appropriately.

This is related to bug 890

the sinfo command is parallelized for performance reasons and it
really can not be completely parallelized for some use cases.
see bug 883

Correct logic to support Power7 processor with 1 or 2 threads per core
(CPU IDs are not consecutive).
bug 891

For "scontrol --details show job" report the correct CPU_IDs when thre are
multiple threads per core (we are translating a core bitmap to CPU IDs).
This is an enhancement of commit 83d626ca
so the node table is only loaded once for the entire job table.
bug 850

If job requests --exclusive then do not use nodes which have any cores in an
advanced reservation. Also prevents case where nodes can be shared by other
jobs.

If job requests --exclusive then do not use nodes which have any cores in an
advanced reservation. Previously the job would be allocated all of the cores
outside of the advanced reservation.

Correct support for partition with Shared=YES configuration.
Previous logic would share resources for jobs by default
(i.e. if user did not explicitly request --exclusive).
bug 758