patchset: add command to test patches on an existing checkout

[bhcopeland]

Add a patchset subcommand that submits patches to the pipeline /api/patchset endpoint, applying them on top of a checkout node created with the checkout command. Patches can be local files uploaded inline or URLs from an allowed domain such as patchwork.kernel.org, with the same job/platform filters and watch options as checkout.

Expose the same functionality as KernelCIClient.trigger_patchset and as a trigger_patchset MCP tool, and document the new command.

This is linked to kernelci-pipeline#1563

[bhcopeland]

kernelci/kernelci-pipeline#1563 linked to this work. We should wait for this PR to go through before testing, but thought be best to put PR up here so we can test.

@nuclearcat FYI. Feel free on any feedback @aliceinwire!

[aliceinwire]

Full patch contents are repeatedly serialized and may be logged
The command permits 32 patches of up to 10 MiB each, meaning an accepted request can contain roughly 320 MiB of patch text
Even when the relevant log level is disabled, the json.dumps() expressions are evaluated before the logging call. Large patchsets therefore create multiple very large temporary strings, increasing peak memory substantially.
Suggestion is to never pass raw patch content to logging. Log only metadata.
Also use lazy logging arguments instead of f-strings for any nontrivial formatting.

safe_data = {
    key: value
    for key, value in data.items()
    if key != "patch"
}
if patches:
    safe_data["patch"] = [
        {"bytes": len(p.encode("utf-8"))}
        for p in patches
    ]

logging.info(
    "Sending patchset request for node %s with %d inline patches",
    nodeid,
    len(patches or []),
)
maestro_print_api_call(url, safe_data)