WFLY-16951 Add necessary individual elytron component jars to jboss-client.jar

[chengfang]

This is a follow-up of 26.x PR #15962 in the main branch.

https://issues.redhat.com/browse/WFLY-16951

It was reported in the above jira that jboss-client.jar worked in 26.0.0 but failed in 26.1.1 for this user's application. In 26.0.0, jboss-client.jar includes everything in wildfly-elytron.jar, which is an uber jar including many of its dependencies and submodules. In 26.1.1, some components like jboss-ejb-client and wildfly-naming-client split their dependency on wildfly-elytron into its more modular individual submodules. Therefore, when building jboss-client.jar, these individual elytron-* submodules are bundled in jboss-client.jar, which omits some artifacts unreachable via transitive dependency.

In order to maintain some kind of compatibility with 26.0.0, this PR proposes to add some additional elytron-* submodules to jboss-client.jar. Even though those additional artifacts are not required at each component client level (e.g., jboss-ejb-client, or wildfly-naming-client), they are needed to support a wide range of non-maven-based applications with various security mechanisms.

The following artifacts are not added to jboss-client.jar in this PR, as they appear not applicable on the client side, but I may be wrong:

elytron-audit
elytron-jacc
elytron-oidc
wildfly-elytron-jose-util
wildfly-elytron-jose-jwk
elytron--deprecated
elytron--http-*

Comment from Farah copied here for easy reference:

@chengfang Thanks for working on this! To make sure that we aren't accidentally missing anything here, I'm wondering if for WildFly 26.1.2, it would be safer to just add a dependency on org.wildfly.security:wildfly-elytron to mimic the behaviour that was present in WildFly 26.0.0.Final? What do you think? That would preserve compatibility.

We can then working on fixing this properly in the main branch. As a starting point, I've added some comments about dependencies that I think can be removed.

I've incorporated Farah's suggestions in the other PR (#15962).

[bstansberry]

@chengfang Note that the module that we're currently using is ee-9/source-transform/client/shade.

I don't see anything in the WF build currently using wildfly-client-all so if you wanted you could update client/shade to the EE 10 deps and then remove ee-9/source-transform/client/shade. We'd need to notify folks a bit in case anyone outside the WF build is using wildfly-client-all-jakarta.

[chengfang]

@bstansberry thanks, I'll update it.

Update: the task of dropping ee-9/source-transform/client/shade is done via #15995

[chengfang]

@fjuma in my manual testing, I found the following deps are still needed on the client side: (you commented in the other 26.x PR that they could be removed, if I read it correctly):

        <dependency>
            <groupId>org.wildfly.security</groupId>
            <artifactId>wildfly-elytron-digest</artifactId>
        </dependency>
        <dependency>
            <groupId>org.wildfly.security</groupId>
            <artifactId>wildfly-elytron-mechanism-digest</artifactId>
        </dependency>
        <dependency>
            <groupId>org.wildfly.security</groupId>
            <artifactId>wildfly-elytron-sasl-digest</artifactId>
        </dependency>

[fjuma]

My comment on the other PR was referring to wildfly-elytron-json-util specifically in that block. Sorry for the confusion, @chengfang!

[bstansberry]

@chengfang @fjuma Can we get this one done in the next day or two? It seems like a good thing to get bake for in 27 Beta1

[chengfang]

I don't have anything else to add. @fjuma can you review again?

[chengfang]

@Skyllarr can you please review it?

[Skyllarr]

The following artifacts are not added to jboss-client.jar in this PR, as they appear not applicable on the client side, but I may be wrong:
elytron-audit
elytron-jacc
elytron-oidc
wildfly-elytron-jose-util
wildfly-elytron-jose-jwk
elytron--deprecated
elytron--http-*

@chengfang Yes these are not applicable on the client side. The PR looks good to me.

[bstansberry]

Thanks @chengfang and @Skyllarr!