No functional change.

Bug 6952.

Call _purge_known_jobs() from _get_runaway_jobs() to purge
known jobs (to slurmctld) from the list.

Removed secondary list runaway_jobs as it was no longer needed.
This also avoids leaking all the runaway_jobs.

Bug 6952.

Bug 6033.

If _get_oldest_record() finds a record to archive/purge, then archive
should always archive at least one record. If for whatever reason it
fails to archive any records (_archive_table() returns a 0), then we
don't want call continue, but want to return an error. Calling continue
to go back to the beginning of the while loop would result in an
infinite loop.

Bug 6033.

Bug 6033.

Trying to archive too many records at once can result in archive files
that are too big to read or even too big to be written. Only archive 50k
records at a time, like we only purge 50k records at a time.

Bug 6033.

The time period of the archive file currently depends on submit or start
time and whether the purge period is in hours, days, or months.
Previously, if the archive file name already exists, we would overwrite
the old archive file with the assumption that these are duplicate
records being archived after an archive load. However, that could result
in lost records in a couple of ways:

  * If there were runaway jobs that were part of an old archive file's
  time period and are later fixed and then purged, the old file would
  be overwritten.
  * If jobs or steps are purged but there are still jobs or steps in
  that time period that are pending or running, the pending or running
  jobs and steps won't be purged. When they finish and are purged, the
  old file would be overwritten.

Instead of overwriting the old file, we append a number to the file name
to create a new file. This will also be important in an upcoming commit.

Bug 6033.

It was set but never read.

Bug 6033.

Change a few variables in archiving to use the correct signed or
unsigned type to avoid implicit casting.

Bug 6033.

Replace "hetjob" with "heterogeneous job" for better clarity.

This just adds addition debugging information to an error message.

bug 6990

Otherwise with CR_CPU and threads defined then slurmd will report
the core count as the CPU count and mess up scheduling.

bug 6990

Bug 6966.

Bug 6799.

Bug 6854

These conflict with JOB_MEM_SET/JOB_RESIZED in 19.05. Since 19.05rc1
has shipped - but no 18.08 maintenance releases have shipped with these
new flags - it is safer to renumber them here to avoid the merge conflict
going into 19.05.

Bug 6064.

Increase the sleep between job end and checking accounting record
from 3 to 5 seconds so the test will work reliably.

test7.20 was always leaving vestigial batch output files and lacked
job time limits (which could leave vestigial jobs on test failure).

bug 6973

Reported as conflicting thread load operations by valgrind --tool=drd.

Bugs 6189 and 4159.

This reverts commit f3d678d4.

Reported as conflicting thread load operations by valgrind --tool=drd.

Bugs 6189 and 4159.

Bug 6783 comment 35.

When tres_usage_in_max field is empty it is recorded as '' in the database
which leads find_tres_count_in_string() to return an INFINITE64. Seff treats
INIFINITE64 as a valid value. This patch fixes this issue.

Bug 6817

Bug 6880/6952.

Bug 6959.

Bug 6944.

Bug 6944.

This is the same because xstrdup returns null on null.
Bug 6812

No real code change.

It appears this is really what this was suppose to be anyway.

Bug 5950

Bug 6064

On requeue, the origin cluster job record is copied to submit
to sibling clusters. If the job was originally submitted
to accept cluster default account, partition, etc, those fields
are now filled in on the origin. Here we add flags to indicate
that those fields need to be cleared on resubmission to siblings.
Bug 6064

This is a holdover from when the fed job_info list was added.
The cluster lock has to be cleared from both the job_ptr and
the job_info.
Bug 6064

Update slurm.spec and slurm.spec-legacy as well.