loadbalancer: Use a sequential execution concurrency model in Default…

…LoadBalancer (#2768)

Motivation:

We use an atomic field and CAS operations to manage concurrency
in the DefaultLoadBalancer. Because the CAS operation has to succeed
before changes have taken affect, it's not easy to make events
coordinate with that model. A few examples:
- it will be awkward to add an event observer to the load balancer since
  we may end up re-doing server-set updates if we fail a CAS.
- there is also a question of ordering of observer events since the
  observer interactions may get out of order wrt the state mutations
  that induced them.
- we can't currently send an LOAD_BALANCER_NOT_READY_EVENT when the
  last host expires because we would risk the event racing with SD
  updates that triggered related events.

CAS failures may also be relatively common due to re-entrance: SD
update events can cause hosts to be closed that that may synchronously
cause the hosts `.afterFinally` listeners to remove themselves from the
host list, resulting in a followup CAS failure.

Modifications:

- use an unbounded processor as a queue for Runnables that are
  executed sequentially and funnel sensitive operations through
  that queue.
- Send the LOAD_BLANACER_NOT_READY_EVENT when a host expires and
  results in an empty host set.