feat(disk-transform): prepare for qcow disks

[fbeauchamp]

Description

the goal of this PR is to define a central point for all disk content transformation, and to port existing backup features

Futures PR will add

• cowd and sesparse source to handle warm import from vmware. (broken for now)
• a qcow producer and a toQCowStream method to be compatible with qcow disk incremental backup and replication
• a xva producer to handle raw import of disk bigger than 2TB (will only work with qcow target)
• more integration tests

Checklist

• Commit
  • Title follows commit conventions
  • Reference the relevant issue (Fixes #007, See xoa-support#42, See https://...)
  • If bug fix, add Introduced by
• Changelog
  • If visible by XOA users, add changelog entry
  • Update "Packages to release" in CHANGELOG.unreleased.md
• PR
  • If UI changes, add screenshots
  • If not finished or not tested, open as Draft

Review process

This 2-passes review process aims to:

• develop skills of junior reviewers
• limit the workload for senior reviewers
• limit the number of unnecessary changes by the author

1. The author creates a PR.
2. Review process:
   1. The author assigns the junior reviewer.
   2. The junior reviewer conducts their review:
      • Resolves their comments if they are addressed.
      • Adds comments if necessary or approves the PR.
   3. The junior reviewer assigns the senior reviewer.
   4. The senior reviewer conducts their review:
      • If there are no unresolved comments on the PR → merge.
      • Otherwise, we continue with 3.
3. The author responds to comments and/or makes corrections, and we go back to 2.

Notes:

1. The author can request a review at any time, even if the PR is still a Draft.
2. In theory, there should not be more than one reviewer at a time.
3. The author should not make any changes:
   • When a reviewer is assigned.
   • Between the junior and senior reviews.

[stephane-m-dev]

In my opinion, if you want to benefit from classes, you should also use private/public/protected/static which go with them, instead of #.

By using #, you only have the choice between public and private.
If we do class inheritance, the properties/methods will either be inaccessible to inheriting classes (private), or accessible and modifiable from everywhere (everything is public = more encapsulation).

[julien-f]

• # is better than private because it is enforced at runtime
• protected does not have an equivalent in ECMAScript, I don't see any issues with using it
• static also exists in ECMAScript
• public is the default when neither private nor protected, I don't see what this annotation brings.

[stephane-m-dev]

"# is better than private because it is enforced at runtime"

TS throws an error if you write code outside the class that accesses a private property or method. So you can't write code that accesses it from outside, it won't even reach runtime.

[julien-f]

TypeScript does the same with private fields: https://www.typescriptlang.org/play/?#code/MYGwhgzhAEDC0G8BQ1XQMQDswFsCmAXNBAC4BOAlpgOZIprAD2mpZArsCY2QBTb5FWVagEpE9NGhIALChAB0WXHmgBeaPzwToAXyR6kTFiWiM1GvAHc4PAOQAzRo1si6R0huXnGizUA

But private fields are standard ECMAScript and are enforced even types are stripped.

[fbeauchamp]

incremental backups works with or without cbt / nbd
missing multi target ( after toolbow merges), throttle , and differential restore

[fbeauchamp]

mirror backups works

[fbeauchamp]

todo :

• ensure disk key in the metadata don't rely on .vhd
• ensure older metadata are also working
• keep the vhd file and directory extension to vhd

next step : v2v