sal-remoterpc-connector: do not use calendar time for Bucket versions

Current Bucket implementation uses System.currentTimeMillis() for versioning, storing them in a Long.

This is completely wrong, as bucket versions as the assumption being made, that the version are always increasing, when:

• during DST changes, when calendar time goes back
• calendar time wraps to negative value

Furthermore it means that we cannot distinguish buckets created in the same millisecond – there is a neat hack to increment the version by one, which is completely useless.

Since we want to maintain binary compatibility, we need to keep on-wire bucket version a Long. Null longs are not allowed, as they cannot be produced by current implementation (and we must never produce them).

To fix versioning here, we will emply a similar strategy to cds-access-api, where we will store versions in akka persistence. Since persisting on each route change would be very slow, we need to split the version space.

Versions are defined to be non-negative longs, i.e. 63 bits. Of these we will steal 31 most significant bits for an 'incarnation number'. The other 32 bits will be used for a 'version number'.

Incarnation Number will be stored in persistence, read/incremented/written every time RpcRegistry starts up.

Version Number is an unsigned 32 bit integer, reset to zero whenever the incarnation number is incremented. Everytime a bucket changes, this version is incremented. Should the version number threaten to overflow, incarnation number is incremented and synchronously persisted before it is sent out.