Corrupt max_cas value in vbucket breaks HLC semantics

max_cas value is maintained in the vBucket to track the mutation with the maximum CAS value that currently exists. This is done to ensure that every CAS value that is generated in the vbucket is monotonically increasing irrespective of the wall clock skew. But a corrupt mutation from, say a DCP stream could set the max_cas to an invalid value -1 (18446744073709551615 because it is an unsigned 64-bit integer). When a new mutation comes into that vbucket, the CAS becomes 0 (which should be the case for only temporary items). Any other operation performed on the item can cause undefined behaviour