Item rev no updated after item is added to hashtable and checkpoint queue

This behavior means that the rev no of the document isn't replicated intra-cluster – or via XDCR. Which has serious implications for XDCR under rev-id conflict resolution.

To repro:

1. create document in UI - notice has rev no. 1
2. delete - tombstone will have rev no. 2
3. create document again in UI - notice has rev no. 3
4. bounce server; notice document now has rev no. 1 – i.e. rev no has gone backwards

Is a regression off 4.6 behavior.