Parallel shard update

The live_upgrade script has been updated to using OTP code change hooks instead of killing off old processes to reload the code. The changes to the `logplex_shard` module include a state record change.  A `code_change` function head has been added to handle this case. The live_upgrade script uses `sys:change_code` to modify the state and resume the running `gen_server`. The `logplex_redis_writer` module is a simple server loop that already handles upgrading to the latest code version.  And `logplex_queue` does not require any state changes between versions.

Resolves a `bin/replace_shards` issue when shard is down caused by the `timer:sleep` call in the `logplex_redis_writer:init` callback.  Under normal conditions the `init` callback is called synchronously and `start_link` will not return until `init` returns. The `timer:sleep` call was causing the supervisor to lock for 1s waiting for the init to finish. This meant each time the downed shard writer (10 of them) failed, it would post-pone even the new shard writers from being setup.

In this case `proc_lib` is used, so it is possible to cheat and ack the init before even attempting to connect to redis. The supervisor is then able to process other child starts, while the writer process is still figuring out if it can even reach the redis instance.


Why was this added, why was it broken?

I remember an old-ish issue where these weren't updated and had to be read from somewhere else (the playbooks mentioned it). Is this the fix for that?

If so, can we expect a related playbook fix?