Add SsmGetCommandInvocationOperator and enhance SSM components

[ksharlandjiev]

Description

This PR adds a new SsmGetCommandInvocationOperator and enhances existing SSM components to provide better command output retrieval capabilities.

Changes

New Features

• SsmGetCommandInvocationOperator: New operator to retrieve output and execution details from SSM command invocations
  • Supports retrieving output from specific instances or all instances
  • Returns structured data with stdout, stderr, execution times, and status
  • Handles errors gracefully with proper logging

Enhancements

• SsmHook: Added get_command_invocation() and list_command_invocations() methods
• SsmRunCommandOperator: Enhanced deferrable mode with proper AWS parameter passing to triggers
• SsmRunCommandTrigger: Improved async execution and AWS connection parameter handling

Testing

• Added unit tests for all new functionality
• Updated the system test demonstrating end-to-end usage

Documentation

• Updated RST documentation with usage examples

Use Cases

This enhancement enables several important use cases:

1. Command Output Retrieval: Get stdout/stderr from SSM commands for downstream processing
2. Debugging: Inspect command execution details for troubleshooting
3. Data Processing: Use SSM command output as input for subsequent tasks
4. Monitoring: Track command execution status and performance metrics

Example Usage

# Run a command
run_command = SsmRunCommandOperator(
    task_id="run_command",
    document_name="AWS-RunShellScript",
    run_command_kwargs={
        "InstanceIds": ["i-1234567890abcdef0"],
        "Parameters": {"commands": ["echo 'Hello World'"]}
    }
)

# Get the output
get_output = SsmGetCommandInvocationOperator(
    task_id="get_output",
    command_id="{{ ti.xcom_pull(task_ids='run_command') }}",
    instance_id="i-1234567890abcdef0"
)

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[o-nikolas]

Thanks for the contribution! Overall it looks quite good. Some feedback:

I don't love the mixture of changes. It's better to make your PRs as tightly scoped as possible, if you spot other things to fix try to do them in a separate PR.

You have some tests failing that need looking into, static checks can be run on your development machine (automatically as well as pre-commit/pre-push hooks), see the docs here for how to run those.

[ksharlandjiev]

Thanks for the contribution! Overall it looks quite good. Some feedback:

I don't love the mixture of changes. It's better to make your PRs as tightly scoped as possible, if you spot other things to fix try to do them in a separate PR.

You have some tests failing that need looking into, static checks can be run on your development machine (automatically as well as pre-commit/pre-push hooks), see the docs here for how to run those.

Thank you for the kind words. Re: Mixture of changes: I understand, and I'll make sure all changes are in their own PR going forward. Please let me know if you want me to revert this commit, and move to a new PR, or I'll be granted exception this time. Thank you!

[o-nikolas]

Thanks for the contribution! Overall it looks quite good. Some feedback:
I don't love the mixture of changes. It's better to make your PRs as tightly scoped as possible, if you spot other things to fix try to do them in a separate PR.
You have some tests failing that need looking into, static checks can be run on your development machine (automatically as well as pre-commit/pre-push hooks), see the docs here for how to run those.

Thank you for the kind words. Re: Mixture of changes: I understand, and I'll make sure all changes are in their own PR going forward. Please let me know if you want me to revert this commit, and move to a new PR, or I'll be granted exception this time. Thank you!

It's all good this time, no need to move to a new PR.

You still have some static checks failing though. Ruff would be automatically fixed for you on pre-commit/pre-push if you enable those :)

[ferruzzi]

Looking good.

[ferruzzi]

Nice, thanks for your work!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[ksharlandjiev]

Nice, thanks for your work!

Thank you both for your leadership and guidance!