Allow use of Octopus with models with custom connection

Only for whitelisted shards, optionally specified by setting a class
attribute via 'allow_shard' on a model which also calls
octopus_establish_connection.

The use case is a model I have that lives in a separate database,
which I do not normally want to have to think about when using it,
but I would like to be able to call "using(:separate_db_replica)"
with an Octopus-managed shard to access a read slave for the model.
Less ambitious change to how current_model works
Need to clean current_model along with current_shard
Fix issue involving cleanup inside block, and update tests

The issue occured when SomeModel.using(:some_shard) was called inside an
Octopus.using block. In this case, clean_connection_proxy was not called
afterwards, because Octopus::Proxy#block was true.

The fix is a bit hacky, but I couldn't find something cleaner. Using
thread-local variables to store shard state in ScopeProxy chains seems
to make everything intrinsically fragile, since unlike with blocks,
there's no good way to guarantee they'll be reset when the caller
assumes they are done with them.

Incidentally this converts specs to the newer syntax.
Looks like should_clean_connection_proxy should check "current_model.replicated || fully_replicated?" not just "@replicated"
Handle nil current_model
Ensure that a single failing replica does not take down the whole application
Do not assume Rails for logger
Avoid connection leak with octopus_establish_connection plus reliance on clear_active_connections!
Make rubocop happy
Support Rails 3 in connection pool loop
Make rubocop happier
acab
Update README for allow_shard
Merge pull request #283 from djudd/master

Allow use of Octopus with models with custom connection