Comment 2 for bug 1998526

Confirmed race in logs comparison between auth.log and the systemctl status output info vs cloud-init.log thanks Anh.

It is strange though that we see an 8 second delay getting the response from the `systemctl status ssh` check and the immediate log line that follows that response. T

We can do one of two things:
 1. shift the point in time for our systemctl status ssh to inspect and restart ssh service only after we are certain we have successfully made ssh config changes.
 2. check something akin to `systemctl is-enabled ssh`, but we would also need to handle socket-activated ssh status on Ubuntu systems in 22.10 and later as systemctl is-enabled ssh will return 'disabled' in those states.

Minimally, I think we reduce exposure to this particular race by moving the logic for the status ssh check after the write/update of sshd_config.

But, ideally, we probably want cloud-init to grow awareness of whether or not ssh service is enabled, but not yet started.
This solution will likely take a bit of time and touch implementation details for both systemd and non-systemd environments via cloudinit.distros.manage_service()