Think about atomizing actions responding to UI and other external state changes

[mayhemer]

When the user enables/disables the proxy, when connectivity or captive portal state changes, we do react to it in the addon with starting a chain of a lot of async/await calls.

While one externally invoked state is being handled, another one can occur as well and start another, concurrent chain of operations.

In all cases we work with (read and modify) the single proxy state (which has several different values, both final and intermediate, and is critical for the addon state) and there can be wrong assumptions about the state to preserve its good health in between await statemements.

I'm thinking of solving this more globally than trying to add state checking after every await statement or in every then() handler.

We may want to have split the proxyState to two states: 1) what state the proxy is in (enabled/disabled/error1/error2/...) and what we are currently doing, what is the in-progress action (nothing, setting online after startup, setting on/offline from UI, reacting to captive portal state changes, ...) When the "action" state is not "nothing" and another change would trigger a different (re)action, queue it instead, and maybe attempt to cancel the current (in progress) action if we e.g. want to go offline while still coming online (obtaining token or testing the connectivity) so that the UI may react quickly to changes.

it would probably mean:

• have some representation of an "action" that would clearly encapsulate all the async steps we are taking to fulfil it, finally updating the proxy status (offline -> online) and any other necessary data (tokens)
• allow sync cancellation of the current in-progress action; I don't mean to block and wait, but to (sync) signal the active action to prevent modification of any of the proxy states and (async) abandon/cancel what it does ASAP
• if sync cancellation model is too hard to implement, possibly have a queue should two ore more actions race (this may make UI updates harder, tho)

@bakulf What do you think?