Fix cancellation of running updates and script-handler CancelUpdate (#776, #777)

[Nox-MSFT]

Summary

Fixes two related cancellation bugs in the agent. Closes #777 and #776.

• Cancel a running Update not working as expected #777 — Cancel of a running update is ignored. The service delivers a cancel with the internal workflow id "nodeployment" both during the pre-deployment delay period and when an operator cancels an update that is already running on the device. OrchestratorUpdateCallback (added in handle nodeployment case #705) treated every "nodeployment" cancel as a NOOP, so an in-progress deployment could never be cancelled and a step handler polling workflow_is_cancel_requested() never observed the request.
• CancelUpdate in script handler is never called #776 — CancelUpdate() in script-handler scripts is never called. ScriptHandlerImpl::Cancel only set the cancel flag and never ran the script's cancel action. In addition, the top-level steps handler's Cancel only set the flag recursively and never dispatched Cancel() to the in-progress child step, so ScriptHandlerImpl::Cancel was never even reached in production. A blocking download/install script cannot observe a flag, so the cancel action must run concurrently to interrupt it.

Root cause & fix

#777

The "nodeployment" cancel is now ignored only when no operation is in progress (the genuine delay-period NOOP). While an operation is in progress, it falls through to ADUC_Workflow_HandlePropertyUpdate, which routes a Cancel action to the in-progress workflow (workflow_init already skips manifest/signature validation for Cancel actions, so the manifest-less payload parses correctly). A new lock-protected accessor ADUC_Workflow_IsOperationInProgress() is used so the orchestrator callback does not read the OperationInProgress flag without the workflow lock.

#776

• StepsHandler_Cancel now dispatches Cancel() to the actively-running leaf child step (tracked under a mutex around the child Install/Apply calls), so the script handler's cancel action is actually invoked. It also stops starting new step work once cancellation has been requested.
• ScriptHandlerImpl::Cancel now runs the script's cancel action (--action-cancel), invoking the author's CancelUpdate(). Because this can run on the main thread while the worker thread is still executing the step's install/apply script, the cancel path uses a non-mutating helper that reads only immutable workflow data and writes to its own dedicated result file — it never writes result/state back to the shared workflow handle, avoiding a data race.

Only the script handler gains active-cancel behavior. The other step handlers' Cancel() (swupdate v2, apt, simulator, reference-steps) are existing flag-set/no-op implementations, so dispatching to them is harmless.

Behavior change & migration

This is a behavior change for script-handler authors: a script's CancelUpdate() function is now actually invoked on cancellation (previously dead code). See the new CHANGELOG.md entry for migration guidance — in short, CancelUpdate() should be idempotent, safe to run concurrently with an in-progress InstallUpdate()/DownloadUpdate(), and return success when there is nothing to cancel. The sample example-installscript.sh already satisfies this, so no example-script changes are required. It cannot break the cancellation outcome and does not affect normal (non-cancel) deployments.

Testing

Built locally (Ubuntu 24.04, Ninja, Debug, --build-unit-tests): 350/350 targets including AducIotAgent, no errors. Relevant unit tests pass:

• agent_workflow_unit_test — 66 cases (incl. new ADUC_Workflow_IsOperationInProgress test)
• script_handler_unit_test — 30 cases (compiles both script + steps handlers; cancel test asserts the cancel-requested flag is recorded)
• steps_handler_unit_tests — 15 cases

Note: the ADO e2e pipeline (definitionId=155, adu-linux-client) should be run against this branch to validate the concurrent cancel path end-to-end.

Files changed

• src/agent/adu_core_interface/src/adu_core_interface.c — conditional "nodeployment" NOOP
• src/adu_workflow/src/agent_workflow.c, inc/aduc/agent_workflow.h — ADUC_Workflow_IsOperationInProgress()
• src/extensions/update_manifest_handlers/steps_handler/src/steps_handler.cpp — active-child tracking, cancel dispatch, loop cancel checks
• src/extensions/step_handlers/script_handler/src/script_handler.cpp — run script cancel action (non-mutating)
• tests + CHANGELOG.md

Out of scope

The SWUpdate v2 handler has the same latent "Cancel only sets the flag" gap; it was left unchanged to keep this PR focused on the reported issues. Can be addressed as a follow-up.