Delete VBucket doesn't reset the vb file revision in the RO kvstore

If the VB's file revision is greater than its default value (due to normal compaction), and then that vbucket is deleted, we do not reset the file-revision which the RO KVStore holds. If that VB is recreated on the node we begin to spam the logs with open errors because every time the RO KVStore accesses the file, it will first try with the high incorrect revision.

So far this appears to only be a problem with log spamming, the couch-kvstore code always finally succeeds to open the correct VB revision because it does a getdirent and scan for a VB file to open.

The fix is to ensure that the RO KVStore has the rev-id cleared on either VB delete or when a VB is recreated.