feat(xo-server): import multiple from ESXi

[fbeauchamp]

Parameter

  concurrency: number of VM import in parallel (during each import, the disks are imported in parallel) 
  host:  esxi host address
  network: XCP network uuid used for the imported VM
  password: esxi host password
  sr: storage uuid used to write the disks
  sslVerify: make esxi certificiate verification, default true, optionnal
  stopSource: stop the source before importing last delta, default false
  stopOnError: stop on the first error , default true . Warning, change the response format
  thin: import thinned disk
  user: esxi host user name
  vms: vm to be imported , json:[2,9,18]

Response :

On success
[esxiVmId]:vmUuuid , for example :

{
  '2': '663d3f9a-5e58-b35b-f720-c1d0922ba6f8',
  '9': 'df9216c2-1b2b-aba6-df76-fdaa80df8c93'
}

On Error: throw an error. If stopOnError is false, continue when an error occurs, throws an error at the end with a succeeded property listing the VM properly imported

Check list

Check if done, if not relevant leave unchecked.

• PR reference the relevant issue (e.g. Fixes #007 or See xoa-support#42)
• if UI changes, a screenshot has been added to the PR
• documentation updated
• CHANGELOG.unreleased.md:
  • enhancement/bug fix entry added
  • list of packages to release updated (${name} v${new version})
• I have tested added/updated features (and impacted code)
  • unit tests (e.g. cron/parse.spec.js)
  • if xo-server API changes, the corresponding test has been added to/updated on xo-server-test
  • at least manual testing

Process

1. create a PR as soon as possible
2. mark it as WiP: (Work in Progress) if not ready to be merged
3. when you want a review, add a reviewer (and only one)
4. if necessary, update your PR, and re- add a reviewer

From the Four Agreements:

1. Be impeccable with your word.
2. Don't take anything personally.
3. Don't make assumptions.
4. Always do your best.

[julien-f]

Move params description in the JSON schema directly.

Documentation should go:

• in code: when it explains the code
• in commit: when it explains the change
• in PR: when it explains PR specific things and how it should be reviewed.

Obviously it's not always obvious but it's the goal.

I'll add any PR doc you don't move to the code directly in the merged commit message

[fbeauchamp]

Move params description in the JSON schema directly.

Documentation should go:

* in code: when it explains the code

* in commit: when it explains the change

* in PR: when it explains PR specific things and how it should be reviewed.

Obviously it's not always obvious but it's the goal.

I'll add any PR doc you don't move to the code directly in the merged commit message

the comment in the PR is to ease @Rajaa-BARHTAOUI work, since she'll implement the front , especially the new options that are not present in single import ( stopOnError, concurrency ) . It can also facilitate the tests.

I think that the comment in the commit won't be as visible