Wait VM becomes getable after triggering restore

[albinsun]

Which issue(s) this PR fixes:

• Issue [TEST] Check flaky tests case TestBackupRestore::test_restore_with_new_vm  #1418

What this PR does / why we need it:

1. ADD vm_checker.wait_getable between api_client.backups.restore and vm_checker.wait_ip_addresses
   • vm_checker.wait_ip_addresses calls api_client.vms.start in the callback chain and will assert FAIL if target VM does not exist.
   • api_client.backups.restore needs some time to communicate with backup-target to restore VM. So depends on the env., VM instance may not be created immediately.

Special notes for your reviewer:

This is a quick fix.
IMO, coder tends to expect function wait_XXX does some polling GET, thus some error-prone. To enhance, we may:

1. Only polling GET and call POST, PUT, DELETE explicitly.
2. Refactor function name to something like create_AAA_and_wait_XXX.
3. ...

Additional documentation or context

Verification

• Before (harvester-runtests#61)
  

• After (harvester-runtests#62)
  

[TachunLin]

LGTM.

Thank you @albinsun for checking and bringing the solution to fix the test_restore with_new_vm related test cases.

I added the vm_checker.wait_getable into all related test case in the test_4_vm_backup_restore.py and also test along with the new class TestBackupRestoreWithSnapshot for PR #1384

And trigger a new test inside the main Jenkins vm toward the raven cluster.

The result is all test_restore_with_new_vm test cases are running well and also PASS most of the backup and restore test cases except those flaky cases already failed before for other reason.

[lanfon72]

I think the root cause would be, we introduced new state while restoring VM, so we should check the restoring process is completed rather than the VM is available.