[SCLPlugin] Fix SCLPlugin enablement triggers

It was found that if a system has `scl` available to it, and has a
non-scl package installed for a plugin that subclasses `SCLPlugin`, but
the scl packages are not installed, then the plugin will not be enabled
even for the non-scl collections.

This was due to a too-restrictive check if the plugin subclasses
`SCLPlugins` that prevented the normal plugin triggers from being
checked.

The future of Software Collections is uncertain to the sos project at
this time, but our current use of it is only 3 plugins; foreman,
postgresql, and redis.

As such, rather than splitting out `SCLPlugin` further into a distinct
separate subclass of a plugin and then having to deal with how to
determine which plugin class should be instantiated if both the scl and
non-scl plugin would otherwise be enabled, make the `SCLPlugin`
enablement conditions not prevent normal plugin enablement, and add
gates to the `_scl` methods provided by `SCLPlugin` to abort any
collection attempt if the specified scl is not detected.

If, at a later date, the project sees further (new) use of the
`SCLPlugin` then we can/will review this approach at that time.

Closes: #2407
Resolves: #2412

Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>

0 files changed, 0 insertions, 0 deletions