Use chef_object_db:add_to_solr in named_data endpoint
Refine darklaunch control of search index queue ops via vhost

This fleshes out darklaunch control of search indexing
operations. The darklaunch flags are:

    disable_rabbit_vhost_chef: if true, DO NOT send data to the default
    /chef rabbitmq vhost.

    rabbit_vhost_chef_solr4: if true, send data to the /chef-solr4
    vhost in rabbitmq.

With latest darklaunch code (which defaults unset keys to false) this
should be safe to load even if disable_rabbit_vhost_chef is not set.

Using multiple vhosts is the easiest approach to allow us to test new
search infrastructure without impacting the live instance while
minimizng the patches needed. The downside of the approach implemented
here is that the vhosts are hard-coded, as is the mapping of
darklaunch key to vhost name.
Send query load to aux solr (ignore results) via darklaunch

If darklaunch key "query_aux_solr" is set to true, then query the
auxillary solr (for testing), ignoring the results. The default solr
server is always queried and its result always returned.

Relies on new chef_wm app config:

    {solr_urls, [{default, "http://default_solr"},
                 {aux, "http://aux_solr"}]}

The solr requests are executed in parallel and the request process
waits for both requests to finish before returning. The latency of the
slower of the two requests will be paid for by the request.
Redo darklaunch switching for testing solr via multiple vhosts

Remove toggle for disabling default vhost. For now, we will always
send data to the default rabbitmq vhost.

Introduce darklaunch key "rabbit_aux_vhost". If true, data for
indexing is sent to the auxillary rabbitmq vhost for indexing.

This relies on a new app config value to map default and aux to vhost
names:

    {rabbitmq_vhosts, [{default, <<"/chef">>},
                       {aux, <<"/chef-solr4">>}]}