[internal/hcs] Migrate package from HCS V1 to V2

[rawahars]

Presently, we were using HCS V1 (vmcompute) within internal/hcs but it has been deprecated and therefore, we are moving to use computecore within hcs package.

[helsaawy]

this change will cause the shim to always block on all operations, right? do we have any perf numbers on how much impact this will have?

[helsaawy]

we always end up calling processHcsResult on the operation result; ie:

	resultJSON, err := runOperation(ctx, func(op computecore.HcsOperation) error { /* ... */ })
	if err != nil {
		return nil, makeSystemError(computeSystem, operation, err, processHcsResult(ctx, resultJSON))
	}

can we elevate hcsResult to an error type (since it already (sorta) matches the ResultError API type), and then move the processHcsResult logic into run[Process]Operation?
that would reduce a lot of boilerplate

[rawahars]

Thanks for the suggestion. Incorporated the same.

[rawahars]

@helsaawy You're right that every call now goes through HcsCreateOperation → API → HcsWaitForOperationResult.

Looking at ClientOperation::HcsWaitResult in computecore, the wait itself is just an event wait, so when HCS completes the work synchronously inside the API call, the wait returns immediately — wall-clock per-operation should be ~identical to V1 (which either completed inline or returned ERR_PENDING and made us wait on a callback anyway).

We are planning on creating a perf calculation tool which can run in CI and can provide us a ballpark of the figures.

[Kavya-Bharadwaj]

MigrationFinalizedOptions takes two parameters Origin and FinalizedOperation. HCS uses Origin to evaluate if this is a normal finalization or a rollback after failure. Omitting origin would lead to wrong recovery path. It's safer to set the origin field here.

[rawahars]

Thanks for the suggestion! I have updated FinalizeLiveMigration to the same pattern as other methods. We will accept the opts which are passed by the caller and will set all the options there.