First pass at ha-sync-mode.
Tweak nodes policy to allow master removal and thus queue migration
remove icky use of element/2
Auto sync when policy changes to require it, in case we are already mirrored but have unsynced slaves at that point.
If we try to stop while starting, wait until we have stopped starting before stopping.
Don't stomp on the (possible) registered name of the thing that invokes boot/0 or start/0, create a new process to hold the name instead.
In case the containing process is trapping exits.
cosmetic
merge bug25419 into stable
merge stable into default
explain
tweak
Merged bug25247
Typo
It's 'name', not 'key'.
Take note of RABBITMQ_SERVICENAME, same as rabbitmq-service.bat does.
make reader's handle_dependent_exit clearer
- handle the no-op case (controlled exit of a channel we've forgotten
  about already) explicitly
- better clause order and formatting.
make reader's handling of channel.close_ok more obviously correct
by re-introducing a call to control_throttle.

This was present in 3.0.x, and is needed there, but is actually not
needed here, due to other changes made in the area. But the reason is
quite subtle...

For control_throttle to do something here, the channel_cleanup would
have to be called for a channel for which we have run out of
credit. Now, credit is only consumed when sending content-bearing
methods to the channel with rabbit_channel:do_flow. There is a
subsequent invocation of control_throttle in the code which will set
the connection_state to 'blocking'. But this is immediately followed
by a call to post_process_frame. The frame we are looking at must be
the last frame of a content-bearing method, since otherwise the method
would not be complete and we wouldn't have passed it to the
channel. Hence that frame can only be a content_header or, more
likely, a content_body. For both of these, post_process_frame invokes
maybe_block, which will turn a 'blocking' into 'blocked'. And from
that point onwards we will no longer read anything from the socket or
process anything already in buf. So we certainly can't be processing a
channel.close_ok.

In other words, post_process_frame can only be invoked with a
channel.close_ok frame when the connection_state is 'running', or
blocking/blocked for a reason other than having run out of credit for
a channel, i.e. an alarm. Therefore forgetting about the channel as
part of the channel_cleanup call does not have an effect on
credit_flow:blocked(). And hence an invocation of control_throttle
will not alter the connection_state and is therefore unnecessary.
refactor: more symmetry in rabbit_reader:handle_dependent_exit/3
It makes no difference whether we call handle_exception before or
after control_throttle, so lets use an order that more clearly calls
out the similarity to the controlled exit case.
explain a reader sublety