Suppress Wildfly test in FIPS JVMs

[DaveCTurner]

Until #32534 is fixed, this suppresses this failing test on FIPS JVMs, but
allows the suite to pass and includes a dummy @AwaitsFix test too.

[jkakavas]

I'm thinking we could extend the check in

elasticsearch/qa/wildfly/build.gradle

Line 181 in 937dcfd

if (!Os.isFamily(Os.FAMILY_WINDOWS)) {

to

if (!Os.isFamily(Os.FAMILY_WINDOWS) && !inFipsJvm) {

so that we skip the integTest in FIPS JVMs.

I also proposed we do this anyway and close #32534, as running our transport client in an application on Wildfly in a FIPS 140 JVM is not something that we cover right now in our FIPS effort

[DaveCTurner]

@jkakavas I've done as you suggested (and in the other place that checks for Windows in that file) and it passes ./gradlew precommit at least. I do not know how to test that this fixes the issue - I don't have a FIPS JVM installed locally. Could you take a look?

[jkakavas]

LGTM, thanks David

[jkakavas]

Could you take a look?

Will do !

I do not know how to test that this fixes the issue - I don't have a FIPS JVM installed locally

I have added instructions on how to troubleshoot test failures in a fips JVM if it ever becomes necessary in the future.

[jkakavas]

I can verify this mutes integTestRunner. But this is a little trickier.
integTestRunner task doesn't fail for me locally.
On CI, it fails on

try (CloseableHttpClient client = HttpClientBuilder.create().build()) {

We don't pass an sslcontext and the defult behavior for HttpClientBuilder is to use the JVMs default keystore and truststore. We however change the JVM keystore to be a BCFKS one for java8fips and we run in the FIPS JVM ( or does Wildfly run in the Gradle's JVM ? ) so it should be able to read it just fine and not fail with

 2> java.io.IOException: Invalid keystore format

I would still like to mute this by merging the PR so that we can continue running the rest of the tests in a FIPS. WDYT @jasontedor ?

[DaveCTurner]

I think it's right to merge this to mute the failing tests, and have done so, but I will leave #32534 open to track any work towards bringing these tests back into the fold again.