Host Checks selection saga

[nelsonkopliku]

Description

This PR adds a saga to enable saving of host checks selection.

Note that:

• the newly added checksSelection slice is intentionally similar to the existing clusterChecksSelection.
  As a followup of this work I'd like to converge to just one slice for check selection based on targetType/targetID for both host check selection and cluster check selection
• UX/UI intentionally resembles the current cluster check selection appareance.
  We'll follow up by aligning both host and cluster check selection to proposed design and get rid of some legacy
• discovered a bug in host projector that emits a host detail with too many null fields, polluting the state when read from websocket (item in the backlog created)

Successful saving

Failed saving

I didn't want to add the bigger refactoring of checks selection saga/state right now. It could have been too much.

How was this tested?

Automated tests added.

[arbulu89]

It looks good in general. I just dropped some comments.
I have some doubts how this will evolve though. What are the "follow up" tasks that you mention in the PR description?

PD:
Don't take the next comment as a blocker to merge the PR.
I personally find difficult to review such a dense PR (that includes changes in some many places). I might have overlooked some changes. I think we should drive to have more atomic things. For example, a PR with the redux state changes, that in this case, would already unify the check selection for clusters/hosts first. Instead of duplicating now the code, and refactoring later (or followup work as you describe). The need for refactoring new code looks like a smell to me.

Because now, we have some redux state as checkSelection which is used only by hosts, but according the name it looks a generic thing.

[jagabomb]

LGTM

[nelsonkopliku]

Thanks @arbulu89 for the feedback!

What are the "follow up" tasks that you mention in the PR description?

Getting to the state you're mentioning 😄

• a revisited redux state and unified checks selection for host and cluster
• adding the navigation from host detail to checks selection
• bringing checks selection and host selection UX/UI to jurgen's proposal
• cleanup the legacy

For the rest I understand it all, it's another way to get to the same place imho.

All in all I am aware of the smells, I just got to make a choice and accept some tradeoffs.
I got to pay a bit the handover when picking up this job and I preferred having a working feature as promised.
This luckily also allows to be more confident in the upcoming required actions.

I didn't think this PR was exceeding the acceptable size, tho 😅
I will take the feedback about more atomic PRs for the future.

[arbulu89]

Ok to merge from my side.
I still have my concerns on how this will evolve and how the different target types checks selection logic will be, but I guess we will see it soon XD

PD: I think we need to have a general consensus on how to write named functions, to know if using global variables inside them is ok or not. I would vote for passing the values as arguments if possible, but I don't even know which is the best practice

[arbulu89]

Wouldn't be better to pass selectedChecks and clusterId as the function arguments?
Using global args looks a bit unsafe.
But talking from my ignorance... XD

[nelsonkopliku]

We would need to have different names tho, otherwise it will clash.
And at the end we would be still passing the same variables, with a different name.

I am open to suggestions.

[arbulu89]

I don't really have a suggestion...
Anyway, now that i checked a bit, we should maybe wrap this functions in useCallback, otherwise the function is redefined in every render. Maybe a cheap operation, but with the useCallback it is avoided.
Maybe @dottorblaster has stronger opinions on this

[EMaksy]

Hey man nice job!
As I'm a bit unfamiliar with Sagas, so I only left a comment --> The rest LGTM :D
Well done.