[REFACTORING] Refactoring the Logic for Resources Monitoring

[PhanLe1010]

We should consider refactoring the logic for engine and instance manager monitoring logic according to this suggestion https://github.com/longhorn/longhorn-manager/pull/854#issuecomment-812101940

The idea is that the monitor is keeping state of the CR and ensuring a requeue of the CR when there is new update. The main sync function will be the one who makes the RS get/update calls to the DS.

DoD

Refactor the controllers:

• [ ] engine controller code
• [ ] instance manager controller code
• [ ] backing image manager controller code
• [x] backup controller code
• [ ] volume/node controller: move the node/volume space usage into a resource monitor we don't have to add the exception for node infomer's resync to be 30s. At the same time we can implement the truncate for the available volume space, since we don't need byte level precision inside of the crds, as long as we truncate down, similar what I did for the node status, since otherwise we would continuously be queuing the volume as long as their is io. https://github.com/longhorn/longhorn/issues/2680

[jenting]

The backup controller is done with this PR.

[innobead]

https://github.com/longhorn/longhorn-manager/pull/1292#issuecomment-1095209547

[innobead]

The new resource monitoring has been introduced at https://github.com/longhorn/longhorn-manager/commit/5788939bf8c558fecaf906c81407dbd048d502dc when the orphan controller gets introduced in 1.3.0. So all the refactoring will be based on this.

cc @derekbit @shuo-wu