Simplify Solr port discovery

* Build the mapping fresh for each search plan.  This avoids issue
  where user changes Solr port.

* Only RPC nodes with the `yokozuna` service running.  This avoids
  issues during upgrade where some nodes will not yet have the
  Yokozuna code.

* Move the mapping functions to the `yz_solr` module since they are
  related to Solr.

* Remove explicit passing of `Mapping` for distributed search.

* If a mapping cannot be determined for each node in the search plan
  then return an error.  Otherwise it would just result in an obscure
  error when calling `yz_solr:shard_frag`.
Remove deadlock from entropy mgr

There is a deadlock where the entropy mgr makes a blocking call to a
KV vnode to get the KV tree pid but that vnode has an incoming write
which makes a call to the entropy mgr to get the YZ tree pid.  Thus a
loop with both waiting on the other.

This commit changes the entropy mgr to gather the KV tree pid in an
async fashion and thus avoid the deadlock.

It might be wise, in a future commit, to change the indexing code-path
to have information like the YZ tree pid pushed to it or stored in
mochiglobal to avoid the blocking call to yz entropy mgr.

I hit this deadlock many times while writing a Riak Search to Yokozuna
migration test.  Following is a copy of the process_info for the
`yz_entropy_mgr` when this deadlock is hit.

```
  [{last_calls,false},
   {backtrace,<<"Program counter: 0x00007f17f9babd70 (gen:do_call/4 + 576)\nCP: 0x0000000000000000 (invalid)\narity = 0\n\n0x00007f1760353280 Return addr 0x00007f17f9c39bc8 (gen_server:call/3 + 128)\ny(0)     #Ref<0.0.0.19936>\ny(1)     'dev3@127.0.0.1'\ny(2)     []\ny(3)     infinity\ny(4)     {riak_vnode_req_v1,913438523331814323877303020447676887284957839360,{server,undefined,undefined},{hashtree_pid,'dev3@127.0.0.1'}}\ny(5)     '$gen_call'\ny(6)     <0.383.0>\n\n0x00007f17603532c0 Return addr 0x00007f17d8508f58 (yz_entropy_mgr:start_exchange/4 + 584)\ny(0)     infinity\ny(1)     {riak_vnode_req_v1,913438523331814323877303020447676887284957839360,{server,undefined,undefined},{hashtree_pid,'dev3@127.0.0.1'}}\ny(2)     {riak_kv_vnode_master,'dev3@127.0.0.1'}\ny(3)     Catch 0x00007f17f9c39bc8 (gen_server:call/3 + 128)\n\n0x00007f17603532e8 Return addr 0x00007f17d8509cb8 (yz_entropy_mgr:maybe_exchange/2 + 464)\ny(0)     <0.2602.0>\ny(1)     {state,automatic,[{182687704666362864775460604089535377456991567872,<0.2595.0>},{274031556999544297163190906134303066185487351808,<0.2598.0>},{548063113999088594326381812268606132370974703616,<0.2600.0>},{639406966332270026714112114313373821099470487552,<0.2601.0>},{913438523331814323877303020447676887284957839360,<0.2602.0>}],[],[],1,[{913438523331814323877303020447676887284957839360,{822094670998632891489572718402909198556462055424,3}},{913438523331814323877303020447676887284957839360,{913438523331814323877303020447676887284957839360,3}},{639406966332270026714112114313373821099470487552,{456719261665907161938651510223838443642478919680,3}},{639406966332270026714112114313373821099470487552,{548063113999088594326381812268606132370974703616,3}},{639406966332270026714112114313373821099470487552,{639406966332270026714112114313373821099470487552,3}},{548063113999088594326381812268606132370974703616,{365375409332725729550921208179070754913983135744,3}},{548063113999088594326381812268606132370974703616,{456719261665907161938651510223838443642478919680,3}},{548063113999088594326381812268606132370974703616,{548063113999088594326381812268606132370974703616,3}},{274031556999544297163190906134303066185487351808,{91343852333181432387730302044767688728495783936,3}},{274031556999544297163190906134303066185487351808,{182687704666362864775460604089535377456991567872,3}},{274031556999544297163190906134303066185487351808,{274031556999544297163190906134303066185487351808,3}},{182687704666362864775460604089535377456991567872,{0,3}},{182687704666362864775460604089535377456991567872,{91343852333181432387730302044767688728495783936,3}},{182687704666362864775460604089535377456991567872,{182687704666362864775460604089535377456991567872,3}}],[]}\ny(2)     {730750818665451459101842416358141509827966271488,3}\ny(3)     913438523331814323877303020447676887284957839360\n\n0x00007f1760353310 Return addr 0x00007f17d85081e0 (yz_entropy_mgr:maybe_tick/1 + 416)\ny(0)     []\ny(1)     []\ny(2)     []\ny(3)     []\n\n0x00007f1760353338 Return addr 0x00007f17d8505948 (yz_entropy_mgr:handle_info/2 + 664)\ny(0)     []\n\n0x00007f1760353348 Return addr 0x00007f17f9c3e6f0 (gen_server:handle_msg/5 + 1680)\n\n0x00007f1760353350 Return addr 0x00007f17f9bb1420 (proc_lib:init_p_do_apply/3 + 56)\ny(0)     yz_entropy_mgr\ny(1)     {state,automatic,[],[],[],1,[],[]}\ny(2)     yz_entropy_mgr\ny(3)     <0.696.0>\ny(4)     tick\ny(5)     Catch 0x00007f17f9c3e6f0 (gen_server:handle_msg/5 + 1680)\n\n0x00007f1760353388 Return addr 0x000000000084f488 (<terminate process normally>)\ny(0)     Catch 0x00007f17f9bb1440 (proc_lib:init_p_do_apply/3 + 88)\n">>},
   {current_stacktrace,[{gen,do_call,4,
                             [{file,"gen.erl"},{line,220}]},
                        {gen_server,call,3,[{file,"gen_server.erl"},{line,184}]},
                        {yz_entropy_mgr,start_exchange,4,
                                        [{file,"src/yz_entropy_mgr.erl"},{line,481}]},
                        {yz_entropy_mgr,maybe_exchange,2,
                                        [{file,"src/yz_entropy_mgr.erl"},{line,560}]},
                        {yz_entropy_mgr,maybe_tick,1,
                                        [{file,"src/yz_entropy_mgr.erl"},{line,413}]},
                        {yz_entropy_mgr,handle_info,2,
                                        [{file,"src/yz_entropy_mgr.erl"},{line,210}]},
                        {gen_server,handle_msg,5,
                                    [{file,"gen_server.erl"},{line,607}]},
                        {proc_lib,init_p_do_apply,3,
                                  [{file,"proc_lib.erl"},{line,227}]}]},
   {message_queue_len,10},
   {messages,[{'$gen_call',{<12760.556.0>,
                            #Ref<12760.0.0.19833>},
                           {get_tree,639406966332270026714112114313373821099470487552}},
              {'$gen_call',{<12760.502.0>,#Ref<12760.0.0.19844>},
                           {get_tree,274031556999544297163190906134303066185487351808}},
              {'$gen_call',{<12760.588.0>,#Ref<12760.0.0.19862>},
                           {get_tree,913438523331814323877303020447676887284957839360}},
              {'$gen_call',{<12760.586.0>,#Ref<12760.0.0.19867>},
                           {get_tree,182687704666362864775460604089535377456991567872}},
              {'$gen_call',{<12760.2603.0>,#Ref<12760.0.0.19942>},
                           {get_lock,build,<12760.2603.0>}},
              {'$gen_call',{<12760.2605.0>,#Ref<12760.0.0.19943>},
                           {get_lock,build,<12760.2605.0>}},
              {'$gen_call',{<12760.2607.0>,#Ref<12760.0.0.19944>},
                           {get_lock,build,<12760.2607.0>}},
              {'$gen_call',{<12760.2604.0>,#Ref<12760.0.0.19945>},
                           {get_lock,build,<12760.2604.0>}},
              {'$gen_call',{<12760.2606.0>,#Ref<12760.0.0.19946>},
                           {get_lock,build,<12760.2606.0>}},
              {'$gen_call',{<12760.587.0>,#Ref<12760.0.0.23763>},
                           {get_tree,548063113999088594326381812268606132370974703616}}]},
   {status,waiting}]],
```
Add `switch_to_yokozuna` API

Add ability to switch handling of HTTP & PB search requests, on the
fly, from Riak Search to Yokozuna.  This is used during migration from
Riak Search to Yokozuna and avoids an extra node restart.
Only pass params which are set

Don't pass query params to Solr if they aren't set.  This fixes a bug
where if you don't use a field name in the query nor set `df` then
Solr would barf with a parsing failure because `&df=` was being passed.
Fix AAE repair, hash object once

Given the right conditions Yokozuna's AAE can enter a state where some
keys are indefinitely repaired.  I.e. the same keys get repaired over
and over.  This turned out to be many things coming together to cause
the bug.

* Use a ring of 16 and 3 nodes, causing node repetition in some
  preflists.

* Two RPC calls, in the repair function, to same node using same
  process.

* The use of the key `tree` for caching the hashtree pid in the
  process dictionary.

Below is a copy of redbug output showing that `yz_kv:get_tree` was
returning the same Pid for two difference partitions.  Ultimately what
this all means is that the hashtree updates were going to the wrong
hashtree and thus AAE kept repairing them.

```
03:51:18 <{erlang,apply,2}> {yz_kv,get_tree,[0]}
03:51:18 <{erlang,apply,2}> {yz_kv,get_tree,1} -> <0.1142.0>
03:51:18 <{erlang,apply,2}> {yz_kv,get_tree,
                                   [1370157784997721485815954530671515330927436759040]}
03:51:18 <{erlang,apply,2}> {yz_kv,get_tree,1} -> <0.1142.0>
```

This commit fixes that by using `{tree,Partition}` as the key for
uniqueness.

I also change the repair function to perform a local get and re-index
rather than cross node boundaries.  This means cheaper repair and no
RPC calls.

Finally, I made a change to where the object hash is calculated to
avoid performing the computation twice.
First pass of Riak Search migration test

This test verifies that Riak Search data can be migrated simply by
letting AAE repair all the missing indexes.  There are many TODOs to
address to make this test even better.  But this is a good first
start.

The verify script now requires 2 arguments.  The dir of a previous
Riak build must be passed which the test will use as the version to
migrate from.
Merge branch 'develop' into test/rz/rs-migration
Merge pull request #163 from basho/test/rz/rs-migration

Riak Search Migration Test 1st Cut + Several Bug Fixes
Merge develop