CmsClient should have a different type object for optimistic locking

[peternied]

In calls like

public Optional<CmsEntry.Index> updateIndexEntry(CmsEntry.Index newEntry, CmsEntry.Index lastEntry);

Two copies of the entry are passed it, this can lead to passing the old for new bugs

This is needed for optimistic locking which requires the current state of the document, by passing the full entry it includes the sequence number and the shard id which are both needed.

If there components were put into a different object type like ETag for the second parameter it would prevent passing the wrong parameter into the function call. I think we do need to clean this up - but lets attack this in future revisions.

Originally posted by @peternied in #693 (comment)

[peternied]

• Resolved in RFS refactoring into separate component programs + new work coordination mechanisms #739