Not used at this point, so drop them from the sbatch/srun CLI.

Leaving them in struct job_details for now, they may be removed at
a future point if the rest of the checkpoint infrastructure is dropped.

Change mem_per_cpu / mem_per_gpu / pn_min_memory / pn_min_tmp_disk
to uint64_t in slurm_opt_t, and use NO_VAL64 as the sentinel value
throughout.

Rework str_to_mbytes2() to return a uint64_t, and NO_VAL64 as an invalid
value instead of -1.

Not needed for now, may come back at a later time.

Only used as part of an info() message hidden behind the --verbose
option in salloc/sbatch/srun, which isn't worth keeping here as
the rest of the slurm_opt_t structure is being cleaned up.

# Conflicts:
#	NEWS
#	doc/man/man5/slurm.conf.5
#	src/plugins/sched/backfill/backfill.c
#	src/slurmctld/job_scheduler.c

This should help insure that jobs are not prevented from running
at the same time on the same node due to memory limits.

bug 6675

Bug 6708.

when acct_policy_job_runnable_post_select() is call for job without
job_resrcs (eg.: from _attempt_backfill() or when select_nodes() can't
find free recource) but with req_node_bitmap.

This patch will change reason of jobs like in test 21.39 from
"JobState=PENDING Reason=QOSGrpNodeLimit" to
"JobState=PENDING Reason=Resources"

bug 6675

Bug 6679

Promote two functions in opt.c to extern, and rename the entry point
to the translation code to xlate_batch_script().

Unused by launch/slurm.

Only works with non-launch/slurm plugins.

There is only launch/slurm currently.

Hasn't been documented since at least version 2.6, and does nothing.

Changed to the documented form before 17.11 was released.

Return an xmalloc()'d string. Clean up string handling to
use xstrfmtcat / xstrcat / snprintf instead of sprintf.

Use that new function in a minimal new cpu_freq_set_env().

Coverity CID 45165

No new functionality, just for clarity and consistency.

Bug 6681

Bug 6681

Broken in commit 9118a41e

Broken in commit 9118a41e

Can now only be used to launch steps in an existing job allocation;
it can no longer be used by SlurmUser to create a new job allocation
with a given jobid value.

Bug 6691.

Bug 6691.

If running within salloc or a job step, both SLURM_JOB_ID and SLURM_JOBID
would be set to the same value, and SLURM_JOB_ID would overwrite SLURM_JOBID
as it is parsed second.

The only time this would cause a difference in behavior is if SLURM_JOBID
were set, and SLURM_JOB_ID were not. Which is not something that can be
caused by Slurm itself.