Support unsubscription of HystrixCommands

[mattrjacobs]

This is a large reorganization of Hystrix internals to support unsubscription.

The changes are:

• Move cleanup actions to happen on the first of terminate/unsubscribe
• Wire up Hystrix state machine as a sequence of operators, rather than using explicit Observable.create
• Be explicit about which state is shared across commands in a request (HystrixCommand.executionResult), and that which is owned by a single command. For example, a command coming from cache, or being cancelled, is only a property of that command, while a SUCCESS is a property of all.

I've added a number of tests to check unsubscription. Outstanding work:

• Let explicit unsubscription trigger a thread interruption. At the moment, only timeouts trigger thread interruptions, while explicit unsubscription triggers a cancellation of the future without a corresponding interrupt.
• Add CANCELLED metrics
• At least one edge case exists for metrics hat isn't handled well at the moment: Command A starts execution, then Command B gets invoked with the same arguments and is supplied by the Observable in Command A. Then, Command A is unsubscribed. The underlying work still goes on, but A's latency stops when it is unsubscribed. Since Command B comes from cache, its latency is 0. So nothing tracks the remainder of the underlying work from when A gets cancelled to its completion.

[mattrjacobs]

This addresses #1199 and #220

[stevegury]

👍
No big deal but a couple of those new Atomic variables could be replaced by volatile variables.

[mattrjacobs]

Thanks @stevegury. Just modified the state in AbstractCommand to be volatile whenever possible

[stevegury]

👍

[mmanciop]

I think the implementation of com.netflix.hystrix.HystrixCommand.queue() is still not compliant with Future.cancel(boolean) as it does not seem to interrupt the execution thread.

[mattrjacobs]

I just created a new issue to track making this work properly: #1268