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.

Make test work if slurm commands or working directory not in search path
move test for FastScheduler value into globals