Refactor operator reconcilliation flow

[l0kix2]

Currently we have an implementation where ytsaurus cluster update flow is hard to understand because it is rather complex and scattered across codebase. As a consequence it is error-prone, hard to maintain and operate on real clusters.

We want to simplify things by implementing an approach where components will be brought to the desired state one after another in strict linear sequence. I.e each reconciliation loop will go through that (well known and explicitly described in a single place of the codebase) sequence, find first component which is NOT in desired state and execute one action which should bring that component closer to the desired state.

We expect that such flow would be easier to understand and also it would be easy to troubleshoot in what stage of update operator and cluster currently are.

As a downside of the approach we expect that linear update of components would be slower, which is might be thing to improve in the future.

[l0kix2]

Here I suggest we touch the components itself as little as possible to keep change simpler and only rewrite manager in sync.go.
I think we should have two flows: creating (Initializing state) and updating (Updating state). Reconcfiguration may be merged with Updating for simplicity of code and everything.
Flows are both linear, but in creating master goes first and in updating master goes last.
At one point in time ytop should update only one component (UpdatingComponents list is always consist of one component) if it allowed by updateSelector and move to the next one after.

[l0kix2]

After today's discussion #396 it seems that we still need 2 update flows: full (as it works now with all pre-steps, after that all pods are removed and after that all after steps) and linear (where only pods of one component are removed at each moment of flow).
I guess we can introduce some flow steps and build 2 different update flows (and create flow i guess) using them.