Add dvv_enabled to .proto definition and codec

[kuenishi]

This pull request is for making basho/riak_cs#1176 finally work. Not mandatory for Riak CS 2.1 release, but hope this merged in 2.1. Do I have to open this against 2.1 branch?

[kuenishi]

mmm, I don't understand why build is failing with this:

riak_pb_codec.erl:350: Invalid type specification for function riak_pb_codec:decode_commit_hooks/1. The success typing is ([any()]) -> [{atom(),atom() | [any(),...]} | {'modfun',atom(),atom() | [any(),...]}]
make: *** [dialyzer-run] Error 1

[kuenishi]

This is now working. Ready for review again :)

[mitchellwrosen]

@kuenishi Still interested in making this happen?

[kuenishi]

@mitchellwrosen I no longer work for Basho and have no permission in this organization. Maybe @russelldb or @martinsumner be interested?

[martinsumner]

@mitchellwrosen you may may wish to appeal for help on postriak.slack.com where Nick Adams and the crew from tiote are active (and have been working on new CS releases). Slack seems to be down for me at the moment, but I will try and find someone to help later.

[EDIT]
Ah, I'm on now and I see you're on there - nadams (tiote) and mcx (bet365) may be best placed to help

[Bob-The-Marauder]

I was reviewing the Riak CS pull requests and noticed this one required the protocol buffers to be patched first. Any thoughts on this?

[martinsumner]

Given that ultimately all it does is warn if dvv_enabled is false, I'm not willing to restart the test cycle to add this in to the 3.0.2 release at this stage. The by-default enabling of dvv has been around for a long time.

Perhaps this might be better resolved by actually enforcing dvv_enabled to be true, and removing the optionality going forward in 3.1 and beyond. There are perhaps a number of other optional configurations (e.g. object format, aae versions) for legacy backwards compatibility that we might want to sweep up.