Description of problem:

When SELinux is disabled (either in /etc/selinux/config or on kernel command line "selinux=0"), it's still possible for setroubleshootd service to start, which leads to a failure:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Mar 16 10:11:21 vm-rhel8 systemd[1]: Starting SETroubleshoot daemon for processing new SELinux denial logs...
Mar 16 10:11:22 vm-rhel8 setroubleshoot[2046]: SELinux not enabled, setroubleshootd exiting...
Mar 16 10:11:22 vm-rhel8 systemd[1]: setroubleshootd.service: Main process exited, code=exited, status=3/NOTIMPLEMENT>
Mar 16 10:11:22 vm-rhel8 systemd[1]: setroubleshootd.service: Failed with result 'exit-code'.
Mar 16 10:11:22 vm-rhel8 systemd[1]: Failed to start SETroubleshoot daemon for processing new SELinux denial logs.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Especially, this happens in two cases:

1. if the user starts the service through command line

1. systemctl start setroubleshootd

2. when "sealert" is started, e.g. by insights-client

1. sealert -l "*"

I think we need to harden the service to avoid these two cases.
For this, I'm proposing to add the following stanzas:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
ConditionSecurity=selinux
RefuseManualStart=yes
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Version-Release number of selected component (if applicable):

setroubleshoot-server-3.3.26-5.el8.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Boot with "selinux=0"
2. Trigger startup using `sealert -l "*"` command

Actual results:

Failure

Expected results:

No failure

Additional info:

Additionally it would be nice to avoid `sealert` from falling in timeout when setroubleshootd cannot start (e.g. because ConditionSecurity=selinux was added).
For now it waits too long before failing:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

1. sealert -l "*"
   ... 25 seconds later ...
   Unable to establish connection to setroubleshoot daemon!
   Check output of 'journalctl -t setroubleshoot' for more details.
   • • • • • • • 8< ---------------- 8< ---------------- 8< ---------------- 8< --------