Add wait_for slurmdbd port

[m-bull]

Ensure that the slurmdbd service is accessible on its specified port after a restart before restarting any other services that
might depend on slurmdbd being accessible.

This fixes an issue where slurmctld is raised before slurmdbd is responding on its port, causing systemctl restart slurmctld to fail with the following message to syslog:

Mar  3 17:02:58 matt-slurm-control-0 slurmctld[63748]: accounting_storage/slurmdbd: clusteracct_storage_p_register_ctld: Registering slurmctld at port 6817 with slurmdbd
Mar  3 17:02:58 matt-slurm-control-0 slurmctld[63748]: error: Sending PersistInit msg: Connection refused
Mar  3 17:02:58 matt-slurm-control-0 slurmctld[63748]: fatal: You are running with a database but for some reason we have no TRES from it.  This should only happen if the database is down and you don't have any state files.
Mar  3 17:02:58 matt-slurm-control-0 systemd[1]: slurmctld.service: Main process exited, code=exited, status=1/FAILURE
Mar  3 17:02:58 matt-slurm-control-0 systemd[1]: slurmctld.service: Failed with result 'exit-code'.

This wait_for approach is already taken when restarting the slurmctld daemon.

[sjpb]

I suspect the actual problem is a mis-ordering here, which currently does:

• "Ensure slurmdbd is started and running" -> starts slurmdbd
• "Flush handlers" -> always restarts slurmdbd, doesn't check it's up, restart slurmctld/d

Maybe under some (TBD) circs slurmdbd is not restarting fast enough. So the proposed check is fine as far as it goes, (although see specific comment too) but I think the flush should be moved BEFORE the "Ensure slurmdbd ..." task. That avoids the bounce (as is done for slurm{ctld/d} and might actually be enough to fix it, although I think the proposed check is good as it will catch an actual fail to start (rather than just a slow startup).

[m-bull]

Tested new changes using Azimuth - problem is still fixed and appliances still provision!