Unify bucket config validation

Current State

Currently the bucket configuration exists in two places:

1) ns_server (for REST API validation)
2) kv_engine

If ns_server passes an invalid bucket configuration to kv_engine when creating a bucket then the bucket will fail to be create in memcached, even though the config has been accepted by ns_server. This will result in the bucket/node(s) remaining unhealthy/yellow in the UI.

Issues

Bucket config validation must be implemented in two different places. It can be time consuming and non-trivial to implement in ns_server as each parameter is implemented individually in code. We've seen bugs in the past where validation was not correct, even though kv_engine originally accepted the configuration.

Proposal

Perform bucket configuration validation in a single place, kv_engine. kv_engine owns the bucket configuration, and are already capable of relational validation of bucket configuration. ns_server would take a proposed configuration from the user via the REST API, and ask kv_engine to validate it. On successful validation ns_server would accept the configuration and use it to create or update a bucket. On validation failure ns_server would forward any error messages provided by kv_engine on to the user.

Potential Concerns

Cluster compat mode checks performed by ns_server can validate that the whole cluster is in some state to support some given parameter, kv_engine can only validate the configuration as the code on the current node understands it. To achieve similar validation checks ns_server could perhaps validate the configuration against all kv_engine nodes in the cluster.

Potential backwards compat handling could be tricky. I'm not sure it's much different to how it should work currently, but warrants more thought.

If we expose the entire bucket configuration to the user via the REST API then they may change settings that we would like them not to (unless recommended by support).

Additional Benefits

Users would now be able to specify and set any parameters via the REST API, i.e. the extra_config_string that ns_server supports to pass additional parameters to kv_engine via diag/eval would no longer be necessary.