ISPN-5528 Expose segment ownership in the Hot Rod client

[gustavocoding]

https://issues.jboss.org/browse/ISPN-5528

Changes in the server:

• Always send numSegments for clustered caches.
• Sends all owners instead of only 2 during topology changes

Changes in the client:

• Added getSegmentsByServer() method that:
  • if there's topology in the server, but hash function is zero, assumes REPL cache and every server is associated with all segments {0...numSegments-1}
  • if there's no topology present (topologyId < 0), associates the server with an empty set (LOCAL cache)
  • If both numSegments and hashFunction are present (DIST) uses the consistent hash to associate the segments to each server

[gustavocoding]

rebased

[gustavocoding]

This PR should be rebased on top of #3511, marking as preview for now

[gustavocoding]

Rebased

[gustavocoding]

Failures not caused by this PR:
Caused by: java.io.FileNotFoundException: /tmp/infinispanTempFiles/StateTransferFileCacheLoaderFunctionalTest1/nbst-with-file-loader.dat (Read-only file system)

Looked at the agents and all have free disk space and /tmp is apparently writable, need to investigate the cause...

[gustavocoding]

rebased

[tristantarrant]

Not sure I like this exposed as public API. Can't we just leave it in RemoteCacheImpl and have code that needs to use this cast to the actual implementation ?

[gustavocoding]

What's your concern of exposing this as public API?

[tristantarrant]

It is definitely not a user-oriented API: however, once it ends up in the public API we have to keep it stable

[gustavocoding]

It is definitely not a user-oriented API

Yeah, it's like a SPI, maybe an advanced API 😄

One of the Remotecache.retrieveEntries accepts a list of segments to filter, IMO it'd be a bit odd to hide getSegmentsByServer since it's a useful complement. We discussed previously the possibility of a AdvancedRemoteCache interface, it's not too late to rescue that idea if there's strong opposition to expose segments & co in the RemoteCache

we have to keep it stable

Not trying to predict the future, but segment ownership by servers is a solidified concept that is not likely to go away anytime soon?

[tristantarrant]

Yeah, I understand, but then I'd probably prefer to encapsulate the return type into an interface like RemoteSegmentMapping instead of Map<SocketAddress, Set> (same for retrieveEntries).

[gustavocoding]

👍 to encapsulate the naked Map

[gustavocoding]

Updated with changes to the API

[galderz]

Looks good, integrated :)