Do not re-load state on a periodic basis as this will break our tracking until
  integrated with actual cray commands and we address race conditions
decrement usage counters when burst buffer teardown completes
Correct burst buffer string parsing for gres
Preeempt allocated buffers for higher priority jobs based upon GRES needs

Add streamlined test to see if a job has any burst buffer component
Add descripitive error if job node list not a valid cray "nid#" format
Replace _get_bb_size() with _get_bb_spec() to support GRES allocations
Fix GRES info pack for "scontrol get burst"
Add GRES allocations to common data structure
Track global GRES usage as allocations are made and removed
Log stage out failure
Gracefully handle bbs_pre_run error
Add some of the logic for preempting burst buffer allocations for higher priority jobs

This reverts commit abc435fd.

Bug 1346

a normal job.

in commit 501b8c1a.

This was broken by commit 2a5271c1
test16.4 was failing since sattach was not setting a protocol version.

Expanded --cpu-freq parameters to include min-max:governor specifications.
--cpu-freq now supported on salloc and sbatch.

Conflicts:
	NEWS

It largely prevents Slurm control over CPU frequency

This test failed once due to a low CPU frequency. Change the logic
to lessen the impact of a low frequency.

Bug 1333

No changes in logic

some redundant code from srun was removed

Previously it was printing a bunch of garbage

It was originally 32-bits so none of the tests for the flag
DEBUG_FLAG_CPU_FREQ in step_mgr.c worked at all.

The --cpu-freq option from the sbatch/salloc command was
NOT logged as part of the RPC
NOT being stored in the slurmctld job record
NOT return as part of the job information once started (even if
    the data structure was populated, which was not the case)

Previous it just printed the value (e.g. "Low") without any
indication of what the information represented.

Conflicts:
	NEWS

Do so only if the CpuFreq DebugFlag is set

The test was assuming the governors configured on a CPU are
available to the job, ignoring the configured CpuFreqGovernors
value.

Removed mkdir (not the critical bit) then test vestigial errno value
so the original cpu environment was never being reset and test1.76 was
consistently failing.

The values are changing between v14.11 and 15.08.

The CPU_FREQ values can not be changed unless logic is added to
do the translation of values from old format command and save/restore
state. Since that logic does not exist, the values were restored
to their original values.