feat: add submission hooks support for job bundles

[rickrams]

Add configurable pre-submission and post-submission hooks that execute during job submission workflow. Hooks are defined in hooks.yaml or hooks.json in the job bundle directory.

Features:

• Pre-submission hooks run before hashing/uploading and can modify payload
• Post-submission hooks run after job creation (non-blocking on failure)
• Hooks receive metadata via stdin JSON and DEADLINE_* environment variables
• Asset references from hooks are merged with existing references
• Configurable timeout per hook (default 60s)
• Works with both CLI (deadline bundle submit) and GUI (deadline bundle gui-submit)

Documentation:

• Added docs/submission-hooks.md with full usage guide and examples
• Updated README.md with submission hooks section

Testing:

• Added 45 unit tests covering models, validation, merging, and execution

What was the problem/requirement? (What/Why)

Being able to execute code before and after job submission. Use cases like setting variables based on the environment or doing introspection for assets for job attachment.

What was the solution? (How)

A new job bundle file called "hooks" that species a command and arguments (similar to how open job description templates do)

What is the impact of this change?

How was this change tested?

I manually tested both CLI and gui submit with a custom script that inspect vrscene files and finds and adds additional job attaachments.

See DEVELOPMENT.md for information on running tests.

• Have you run the unit tests? Yes
• Have you run the integration tests? Yes
• Have you made changes to the download or asset_sync modules? If so, then it is highly recommended
  that you ensure that the docker-based unit tests pass.

Was this change documented?

• Are relevant docstrings in the code base updated? Yes
• Has the README.md been updated? YEs

Does this PR introduce new dependencies? No

This library is designed to be integrated into third-party applications that have bespoke and customized deployment environments. Adding dependencies will increase the chance of library version conflicts and incompatabilities. Please evaluate the addition of new dependencies. See the Dependencies section of DEVELOPMENT.md for more details.

• This PR adds one or more new dependency Python packages. I acknowledge I have reviewed the considerations for adding dependencies in DEVELOPMENT.md.
• This PR does not add any new dependencies.

Is this a breaking change? No

A breaking change is one that modifies a public contract in a way that is not backwards compatible. See the
Public Contracts section
of the DEVELOPMENT.md for more information on the public contracts.

If so, then please describe the changes that users of this package must make to update their scripts, or Python applications.

Does this change impact security? Potentially. It executes scripts that could be malicous or potentially misused or hijacked.

• Does the change need to be threat modeled? For example, does it create or modify files/directories that must only be readable by the process owner?
  • If so, then please label this pull request with the "security" label. We'll work with you to analyze the threats.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rickrams]

Updated to allow for two independent hook sources, each with its own security setting:

Hook Sources

1. Bundle Hooks - hooks.yaml in job bundles

• Controlled by settings.allow_bundle_hooks (default: false)
• For workflows where hooks are bundled with job templates

2. Environment Hooks - DEADLINE_HOOKS_DIR environment variable

• Controlled by settings.allow_environment_hooks (default: false)
• For studios that want to enforce hooks across all submissions without modifying job bundles or submitter code

Security Model

Both sources are disabled by default (opt-in). When enabled, users see a confirmation prompt showing exactly which commands will run before execution (unless auto_accept=true).

Studio Deployment Example

# IT configures workstations once
deadline config set settings.allow_environment_hooks true

# Per-application launcher scripts set the hooks location
# blender_launcher.sh
export DEADLINE_HOOKS_DIR=/studio/pipeline/hooks/blender
exec blender "$@"

# maya_launcher.sh  
export DEADLINE_HOOKS_DIR=/studio/pipeline/hooks/maya
exec maya "$@"