Add multiple update selectors

[wilwell]

No description provided.

[l0kix2]

Please rebase on the main branch since #387 is merged — which have couple of new stages in the flows

[l0kix2]

Let's not remove updateSelector stuff for now. We are shooting ourselves in the leg that way, since we ourselves need some time to migrate from updateSelector to updateSelectors.
Let's just add deprecation comment and remove it it next releases when we migrate.

I suggest we have some function, which would receive ytsaurus spec and return updateSelectors values.
It should be easy to unittest it for all major cases, which are:

1. if updateSelectors is not nil/empty list — we return it as is
2. if updateSelectors is nil/empty list and updateSelector != UpdateSelectorUnspecified — we convert it's value to the updateSelectors value. Rules are:

UpdateSelectorNothing > []ComponentUpdateSelector{{ComponentGroup: consts.ComponentGroupNone}}
UpdateSelectorStatelessOnly > []ComponentUpdateSelector{{ComponentGroup: consts. ComponentGroupStateless}}
UpdateSelectorEverything > []ComponentUpdateSelector{{ComponentGroup: consts.ComponentGroupEverything}}

UpdateSelectorMasterOnly > []ComponentUpdateSelector{{ComponentType: consts.MasterType}}
UpdateSelectorDataNodesOnly > []ComponentUpdateSelector{{ComponentType: consts.DataNodes}}
UpdateSelectorExecNodesOnly > []ComponentUpdateSelector{{ComponentType: consts.ExecNodes}}
UpdateSelectorTabletNodesOnly > []ComponentUpdateSelector{{ComponentType: consts.TabletNodes}}

3. if updateSelectors is nil/empty list and updateSelector == UpdateSelectorUnspecified we convert enableFullUpdate to the updateSelectors value. Rules are:

enableFullUpdate=true > []ComponentUpdateSelector{{ComponentGroup: consts.ComponentGroupEverything}}
enableFullUpdate=false => []ComponentUpdateSelector{{ComponentGroup: consts.ComponentGroupStateless}}

[l0kix2]

Since we have combination of selectors that wouldn't be possible to cover with existing flow (like like master+http proxies will go to everything and will update tablet nodes which wasn't allowed by selector) we have to make changes in flows code.
Also we've discovered that we already have checks like needSchedulerUpdate and needQueryTrackerUpdate we simplify code a bit and just have one "EverythingFlow" with added ifs for the master and tablet nodes in the required places. Other flows and flow field itself can be removed with this change — that would make less copypaste and possible errors in the code.

The thing which is bothers me that this flows is not test covered very well and it is rather expensive (in the meaning of test time and code amount) to test all the required cases in e2e.
So I suggest we convert this flows code with switch-cases in a different shape. We introduce some struct like this

type flowStep struct {
  name string
  condition func(ytv1.Ytsaurus) bool
  onSuccess func() err
}

and have some function to build flow from the list of exact components which require update

func buildFlow(components) []flowStep{
    var steps []flowStep
    if components.Contain(masterType) {
        steps = append(flowStep{
             name: "safe mode enabled",
             condition: func(ytsaurus ytv1.Ytsaurus) {
                 return resource.Status.UpdateStatus.State == `ytv1.UpdateStateWaitingForSafeModeEnabled`
             },
             onSuccess: func(ytsaurus ytv1.Ytsaurus) {
                 return ytsaurus.SaveUpdateState(ctx, ytv1.UpdateStateWaitingForTabletCellsSaving)
              }
        })
    }
    ...
    return steps
}

(I'm not sure that this exact fields and functions should be there, but something similar should work).

That way we can cover our flow building with fast unittest good enough and cover all the important cases and be sure not to break stuff in flow logic.

So the whole code for this PR will look like this:

1. convert fullUpdate+updateSelector+updateSelectors to the updateSelectors list
2. get components which require update and filter them with updateSelectors — set it to the updating components field of UpdateState and set state=Updating
3. generate flow for the list of the componenents
4. apply the flow

all 1-3 steps can be untitested that way.

I think it is better to do it in the separate PR and after that use that code in this PR.
What do you think? Does it make sense to you?