Extend RestrictedSecurity constraints

[KostasTsiounis]

The functionality of the provider constraints in RestrictedSecurity profiles is extended. Instead of allowing them to be universally used, one can optionally indicate the specific module and/or class from where a particular cryptographic algorithm can be called.

Tests are, also, added to test the new functionality offered through RestrictedSecurity profiles.

Signed-off-by: Kostas Tsiounis [email protected]

[keithc-ca]

I think this should support more than one use for any given algorithm. For example, we might want to allow both UUID and TestConstraintsSuccess to use MD5:

    {MessageDigest, MD5, *, ModuleAndFullClassName:java.base/java.util.UUID, FullClassName:TestConstraintsSuccess}

(ignore for the moment whether comma is the right separator for acceptable uses)

[KostasTsiounis]

I think this should support more than one use for any given algorithm. For example, we might want to allow both UUID and TestConstraintsSuccess to use MD5:

    {MessageDigest, MD5, *, ModuleAndFullClassName:java.base/java.util.UUID, FullClassName:TestConstraintsSuccess}

(ignore for the moment whether comma is the right separator for acceptable uses)

We considered this as an option, but we came to the conclusion that it might become convoluted and is kind of error prone. Instead, one can have multiple constraints per algorithm. For example:

 {MessageDigest, MD5, *, ModuleAndFullClassName:java.base/java.util.UUID},
 {MessageDigest, MD5, *, FullClassName:TestConstraintsSuccess}

[keithc-ca]

Please squash.

[keithc-ca]

Jenkins test sanity alinux jdknext

[keithc-ca]

The sanity.openjdk failure should be resolved by adoptium/ci-jenkins-pipelines#1191.