Add single-argument method version for binary compatibility

[acogoluegnes]

A recent commit in 5.3.2 broke the binary compatibility with modules like JGroups K8S. It's no longer possible to use JGroups K8S 2.0.1 with JGroups 5.3.2:

Caused by: java.lang.NoSuchMethodError: 'org.jgroups.util.ByteArray org.jgroups.protocols.kubernetes.KUBE_PING.marshal(org.jgroups.protocols.PingData)'
        at org.jgroups.protocols.kubernetes.KUBE_PING.findMembers(KUBE_PING.java:278)
        at org.jgroups.protocols.Discovery.callFindMembersInAllDiscoveryProtocols(Discovery.java:393)
        at org.jgroups.protocols.Discovery.findMembers(Discovery.java:240)
        at org.jgroups.protocols.Discovery.down(Discovery.java:430)
        at org.jgroups.protocols.MERGE3.down(MERGE3.java:268)
        at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:102)
        at org.jgroups.protocols.BARRIER.down(BARRIER.java:138)
        at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:635)
        at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:653)
        at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:275)
        at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:67)
        at org.jgroups.protocols.pbcast.ClientGmsImpl.joinWithStateTransfer(ClientGmsImpl.java:41)
        at org.jgroups.protocols.pbcast.GMS.down(GMS.java:898)
        at org.jgroups.protocols.FlowControl.down(FlowControl.java:201)
        at org.jgroups.stack.Protocol.down(Protocol.java:309)
        at org.jgroups.protocols.FRAG2.down(FRAG2.java:103)
        at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:205)
        at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:947)
        at org.jgroups.JChannel.down(JChannel.java:601)
        at org.jgroups.JChannel._connect(JChannel.java:803)
        at org.jgroups.JChannel.connect(JChannel.java:373)
        at org.jgroups.JChannel.connect(JChannel.java:346)

This PR adds back the static ByteArray marshal(PingData) method and delegates calls to the new varargs-version one.

[belaban]

Ouch! I'll add that method back to JGroups, will post the JIRA here...

[belaban]

https://issues.redhat.com/browse/JGRP-2761

[belaban]

I wonder what other discovery protocols are affected by this... jgroups-aws? @rhusar ?

[acogoluegnes]

Client code still compiles (see https://github.com/jgroups-extras/jgroups-kubernetes/actions/runs/7727049508). It's only when you choose to override the JGroups version in your project and not take the version (transitively) from the module. That's what I do in my project (JGroups K8S 2.0.1, which depends on JGroups 5.2.2, but I use JGroups 5.3.2).

I may not be the only one doing this, so it's safer to keep the binary compatibility I guess. Thanks for the quick follow-up.

[rhusar]

I wonder what other discovery protocols are affected by this... jgroups-aws? @rhusar ?

Even though we keep JGroups versions up to date in the external projects, given that this is binary compatibility issue, our tests wouldn't be able to detect that, since everything will compile alright and tests will pass.

We need to come up with better handling (at least testing) for this.

It's only when you choose to override the JGroups version in your project and not take the version (transitively) from the module. That's what I do in my project (JGroups K8S 2.0.1, which depends on JGroups 5.2.2, but I use JGroups 5.3.2).

We don't do 1:1 mapping of jgroups and external protocols releases. So this is a very common situation, nothing unusual.