Add support for deletedvclock=true

[lucperkins]

As far as I can tell, there is no way to set deletedvclock to true for read requests using the 2.0 client.

[seancribbs]

Interestingly, this will have no effect on HTTP. For consistency, it should just be assumed true in the server-side API. Until then, we'll use True in the client.

[seancribbs]

Proposed longer-term solution:

1. Always send deletedvclock = True in the clients.
2. Update riak_kv_pb_object to ignore the field in the PB message, assuming it's true.
3. Remove the field from the message definition.
4. Update clients not to send the field at all.

This assumes that always returning the vector clock for tombstones is a good thing. From a causal point of view, it is the only reasonable answer, but I'm sure someone will disagree with me on that.

/cc @broach @bkerley @javajolt @macintux @jonmeredith

[macintux]

#enocontext. Somehow I've overlooked this; is this a new 2.0 feature?

[seancribbs]

@macintux No, this flag has been here a while. See Also

[seancribbs]

On another note, it seems it is already set to true by the transport, if the "tombstone_vclocks" feature is available.

[macintux]

Returning it every time seems like a no-brainer, except in really odd situations where you're deleting a lot of keys and then querying them within the tombstone retention period. I don't know why this is even configurable, but it should be true by default.

[seancribbs]

@macintux Agree.

[seancribbs]

I think we should go ahead and close this, I have a separate pull-request brewing that will add a few more quorum parameters to get.