[IMPROVEMENT] Remove the BackupVolume CRD

[jenting]

Is your improvement request related to a feature? Please describe

The BackupVolume CRD should be able to remove, all the information that BackupVolume CR required should be able to get from the Backup CRs. This could make the user only need to know how to prepare the Backup CR only without having the knowledge on that BackupVolume CR.

Describe the solution you'd like

Remove the BackupVolume CRD.

Describe alternatives you've considered

None.

Additional context

• https://github.com/longhorn/longhorn/issues/2798 (since we all checks the backup configs, it would cease the possibility that backup volume config and backup config out of sync)
• https://github.com/longhorn/longhorn/issues/1268#issuecomment-985298021, https://github.com/longhorn/longhorn/issues/3168 (we are able to show the progress bar or error message on the Backup page once we remove BackupVolume CRD which means all the information for BackupVolume come from Backup CRs)
• https://github.com/longhorn/longhorn/issues/3082 (since we remove the BackupVolume CRD, during the uninstallation process, unset BackupTarget URL, the backup_target_controller clean up all the Backup CRs rather than clean up the BackupVoulme CRs then Backup CRs code)

[joshimoo]

Leaving some notes below,

In the case where we require additional metadata / want to remove the volume.cfg or change the backup.cfg. This is a good time to introduce versioning to the backupstore, see ref: https://github.com/longhorn/longhorn/issues/3175#issuecomment-948774221

Since then the backupstore can be responsible for rendering and returning a newer version DTO based on the old information. While all new backups would be created with the new version.

Reason for versioning:

• allow for compression choices, based on @derekbit compression comparison lz4 looks pretty good so even if we don't allow choices just yet. REF: https://github.com/longhorn/longhorn/issues/1409#issuecomment-948693046
• bigger block sizes, this one is great for reducing the S3 cost and lowering the amount of S3 calls required, this might also help further with the compression reduction for compressible data, since the overall amount of data that is being looked at by the compressor is higher.
• new metadata (yamls, preferably backup.yaml directly from the custom resource, other yamls (workloads yaml, jobs.yamls, secrets.yaml (crypto etc))

Other improvements:

• need to add S3 rate limiting, with bigger block sizes, this becomes less of an issue, right now thoug at 2MB blocks this is a concern. REF: https://github.com/longhorn/longhorn/issues/2810
• parallel backup process, there are concerns around io priority etc, REF: https://github.com/longhorn/longhorn/issues/1409#issuecomment-948782515