Appliance: Minion fails to come up with 30.x and bleeding image

Appliance: Minion container fails to come with 30.x and bleeding image.

The OpenNMS Minion appliance launched a minion docker container.

The appliance (dominion) uses a local and passive minion health-check query every 5 seconds as a readiness check.  If after 5 minutes, a successful response has not been returned, dominion respawns the minion container.

With the latest release-30x and bleeding images, the Minion is in a respawn loop because dominion gets a 401 response to the minion health-check.

j-white pointed to this issue having been introduced by https://github.com/OpenNMS/opennms/pull/4885.
This PR added some explicit dependences on the JCEKS implementation of SCV, which made it's way down to Minion
 
Minion in the appliance, actually changes the SCV implementation to be gRPC-based, and it feeds it credentials from there, so the JCEKS implementation is not present, and we see this problem
 
 
here's the alternate SCV implementation for reference: https://github.com/OpenNMS/opennms/blob/develop/features/scv/dominion-grpc-impl/src/main/resources/OSGI-INF/blueprint/blueprint.xml#L26
 
That code path isn't actually used on Minion (it doesn't connect to the DB), so we may be able to work around with with some OSGi wiring or bundle header changes

This issue blocks the release of the next H30 release.