Re-evaluate our systemd.service Type config

[phillxnet]

Further to @Hooverdan96's work against #2650, it is proposed that we re-evaluate our systemd Type= settings (either implied or explicit) for all existing and incomming (in testing) services.

Post our incoming changes against #2650, we have the following upon rpm install and systemctl enable --now rockstor-bootstrap

systemctl list-units --type=service --state=active | grep rockstor

...
  rockstor-build.service                   loaded active exited  Build Rockstor
  rockstor-pre.service                     loaded active exited  Tasks required prior to starting Rockstor
  rockstor.service                         loaded active running Rockstor SGI Service
  rockstor-collector.service               loaded active running Rockstor Collector Service
  rockstor-scheduling.service              loaded active running Rockstor Scheduling Service
  rockstor-replication.service             loaded active running Rockstor Replication Service
  rockstor-bootstrap.service               loaded active exited  Rockstor Bootstrapping Tasks

The above output is re-orders to indicate typical expected start-up order and does not include our rockstor-nginx-override.conf as this is not a service. It also includes the single non-default service of rockstor-replication.service as having been enabled.

N.B. we have a number of different types of services here to wrangle - and the primary objective of this issue is to assess our existing use of type=simple in some cases as it does not await the ExecStart binaries completion prior to launching dependant services: potentially causing failure in these dependant services.

---

See also: #3034 (comment)
Upstream referenced: https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#Type=

[phillxnet]

Post reboot for the above referenced rpm:

systemctl list-units --type=service --state=active | grep rockstor
  rockstor-pre.service                     loaded active exited  Tasks required prior to starting Rockstor
  rockstor.service                         loaded active running Rockstor SGI Service
  rockstor-collector.service               loaded active running Rockstor Collector Service
  rockstor-scheduling.service              loaded active running Rockstor Scheduling Service
  rockstor-bootstrap.service               loaded active exited  Rockstor Bootstrapping Tasks


multi-user.target @51.046s
└─rockstor-bootstrap.service @39.353s +11.691s
  └─rockstor-scheduling.service @39.347s
    └─rockstor.service @39.337s
      └─rockstor-pre.service @12.397s +26.919s
        └─chrony-wait.service @3.224s +9.125s
          └─chronyd.service @2.759s +445ms
            └─network.target @2.730s
              └─NetworkManager.service @2.241s +486ms
                └─dbus.service @2.232s
                  └─basic.target @2.203s
                    └─sockets.target @2.202s
                      └─dbus.socket @2.201s
                        └─sysinit.target @2.181s
                          └─systemd-update-utmp.service @2.149s +27ms
                            └─auditd.service @2.036s +87ms
                              └─systemd-tmpfiles-setup.service @1.953s +67ms
                                └─run-credentials-systemd\x2dtmpfiles\x2dsetup.service.mount @1.965s

Which looks to suggest we have a regression re rockstor-replication.service enablement post reboot. On the system in question there were no replication task entered - just the basic replication config established. Also not directly related to this issue.

[EDIT] The above noted regression has now been issued as per:

• Regression re rockstor-replication.service enable #3045