Editorial comment: really awesome to see the monstrosity of riak_kv_pb_socket broken up

What about some lager output here in the case that a user is upgrading and uses an old config. I actually did just that and the error when the riak_api section is missing is non-obvious.

Is it just me, or did the rpbgetserverinforeq disappear?

@rzezeski It has moved to riak_api.

I see a lot of failures with the Java client integration tests on a devrel. The entries in the crash.log aren't helping much as they just show the incoming message and {error, function_clause}. Currently master of riak is broken because the PB work is half merged (which I take full responsibility for). I'd like to get this wrapped up today so master will build again.

I discovered what the problem is after tracing at debug level on the riak_api_pb_server. I don't like that we catch errors and then only show stack if debug level is set. This means that when a customer encounters an error like this we have to show them how to use debug level tracing so we an see the actual exception. I say all those debugs should be logged with at error. Or at least return the stacktrace along with the reason so the logs aren't useless.

The new decode_quorum slightly breaks old behavior of normalize_mumble. The old function did not have a guard to check that argument is integer. Please revert to old logic for now so things don't break.

@rzezeski Early feedback from @jonmeredith indicated that a frequently failing client would spam the logs, hence the level was lowered to debug from info. Also, the client should receive the error message in an rpberrorresp, although i admit it's not as useful as a full backtrace. Again, the desire here is to warn the client before stopping abruptly so the error can at least go through the client error handling logic.

The problem is that what is returned to the client is useless. Either the stack needs to be formatted with it or we need to change from debug->error (it's an error, lets log it as one).

catch
    %% Tell the client we errored before closing the connection.
    Type:Failure ->
        lager:debug("Message processing error: ~p:~p ~p", [Type, Failure, erlang:get_stacktrace()]),
        send_error("Error processing incoming message: ~p:~p", [Type, Failure], State),
        {stop, {Type, Failure}, State}
end

I've reviewed this code, compiled it, ran unit tests, and most of the Java client integration tests are running. I'm going to merge this in master so that it builds again and file issues for remaining failures.