if a callable is sent on a random target, subsequent cancel operation on it should use previously known target
use TargetCallable for refreshable requests
revert unintended volatile change
remove unintentionally added overrides
get refreshed target for cancellation also
Enhanced logging of testMapDestroyIssue764().
#3796

When a partition is promoted from a backup to a primary then QueueContainer iterates through collection of existing backup values and set its own IDGenerator to the highest itemID found in backups.

However chances are the backup collection doesn't contain all records created by the old primary as some backup operations can still be in-flight. This leads to duplicated IDs generated by the new primary.

 This fix simple adds an offset so the new owner always generates IDs significantly higher then the previous owner. The down-side is the generated ID are no longer continuous, but I don't see this as a problem.
(cherry picked from commit aadf683)
Merge pull request #4286 from jerrinot/fix/queue-losing-messages/3.x

Backport of #4275
Merge pull request #4232 from ahmetmircik/fix/3.3.4/futureCancelOnRandomTarget

Fixes cancel operations target address after sending a callable on a random target
Extracted assertion logic to private method to cleanup test.
Merge pull request #4283 from Donnerbart/fixIssue4237in3x

Enhance logging of test to see if issue #4237 is still occuring.