WFLY-17047 Weld Probe removal

[manovotn]

JIRA - https://issues.redhat.com/browse/WFLY-17047

This PR does not contain Weld version update yet, just changes related to Probe removal
EDIT: Weld 5.1.0 is now syncing with Central and this PR will contains the updated version as well.

[wildfly-ci]

Hello, manovotn. I'm waiting for one of the admins to verify this patch with /ok-to-test in a comment.

[manovotn]

Since there was no other than Alpha release of WFLY, I have decided it would be cleaner to change weld subsystem 5.0 to not accept devel mode property at all.
However, this draft is currently failing in WeldSubsystemTestCase because older subsystem versions can have this property.
Any hints on what's the proper way to handle this @bstansberry? I tried looking into WeldTransformers, but that seems to be for the opposite case (where you have newer config and need to adapt it to older) - but I am probably just missing something, right?

[github-actions]

Dependency Tree Analyzer Output:

Removed Dependencies:

• org.jboss.weld.probe:weld-probe-core:jar:5.0.1.Final:compile

CC @wildfly/prod

[darranl]

I have had to do what Brian is suggesting here where I have been disabling the security-realm attribute across subsystems e.g.

#16107

In my case I also report an error at runtime if set but that is probably a step too far for this attribute.

[manovotn]

What about the test failures I mentioned above? I am not quite grasping how are tests such as this supposed to behave when an attribute is being removed from newer version.

[manovotn]

I'll get back to this later today.
Looking at @darranl PR, I think I understand what you meant. Latest version of schema still needs to support dev mode attribute, but it will be a no-op.

[manovotn]

The PR is now changed to remove Probe as a dependency but it retains Weld devel mode configuration option as it was, only deprecates it.
Is this what you meant @bstansberry @darranl ?

[manovotn]

Hello, manovotn. I'm waiting for one of the admins to verify this patch with /ok-to-test in a comment.

BTW I don't think I can trigger this either :)

[bstansberry]

/ok-to-test

[bstansberry]

This LGTM @manovotn

As @darranl said it's possible to throw an OperationFailedException if this is set to true, e.g. at https://github.com/wildfly/wildfly/blob/main/weld/subsystem/src/main/java/org/jboss/as/weld/WeldSubsystemAdd.java#L88, but I think that's overkill. (That code only executes in a server that's running in normal mode.) Doing that would interfere with people using a particular config in different dev environments, without adding a ton of value vs the WARN that gets logged.

[bstansberry]

Thanks @manovotn!