The truncation of '1500 GB' to (integer) '1 TB' is missleading. Make
sure, we show a decimal place. Also use binary prefixes (e.g. KiB
instead of kB) and correct the computation to binary prefixes where it
is wrong.

Factor out reusable code into a new function
could_potentially_start_job_for_user.

Factor out reusable code into new function can_start_job.

If a user is waiting for free resources, don't start jobs for later
users, even if the later user doesn't have his so-called "fair share" of
the cluster.

Keep the (now unnecessary) "waiting"-flag, because we are adding another
clause to the condition in the next commit.

Hoist up df_scratch one calllevel.

Only advertise WAITING state if there are jobs which could be started
on this server.

_mx_sort_linked_list and its macro wrapper mx_sort_linked_list currently
do a stable sort. Add comments to the code and the test that this is
guaranteed behaviour, because we are going to depend on it in the
following commits.

We are going to rely on the stability of the user list as a secondary
preference criteria to the number of jobs running in the cluster.

Put new user at the end of the user list so they start behind other
waiting users and will stay behing them if the main crtieria
(running_global_slot_count) is equal (e.g. zero).

Move a user, for whom a job was started, to the end of the user list.
This way the server will do round-robin between users who have otherwise
equal precedence based on running_global_slot_count.

Avoid sorting the user list when we are not going to start a job anyway.
Also save a few source lines and remove a dead initalization.

gcc shows "warning: ‘status’ may be used uninitialized in this function
[-Wmaybe-uninitialized]" on higher optimization levels.

The variable will not be unitialized, if the code logic and the kernel
process modell and system calls work as expected, but the compiler
doesn't know about that.

Initialize variable to a dont-care value to silence the compiler.

Add initalizations to avoid false warnings.