Implement ORB AWS EC2 Worker Adapter

[magniloquency]

This pull request implements the ORB AWS EC2 Worker Adapter (orb_aws_ec2), enabling Scaler to dynamically scale worker instances on AWS using the ORB Python SDK (replacing the original CLI-based approach).

Key Changes

• ORB SDK integration: Replaced ORBHelper (subprocess wrapper around the orb CLI) with direct ORBClient SDK usage. Config is built in-memory from ORBAWSEC2WorkerAdapterConfig fields — no file copying, no temp dirs for templates or user data.
• Removed orb_config_path: No longer needed; the provider config is constructed programmatically via _build_app_config().
• Async polling: _poll_for_instance_id() is now fully async (asyncio.sleep instead of time.sleep + run_in_executor).
• AMI Building: Introduced ami/ directory with Packer configuration (opengris-scaler.pkr.hcl) and a build script (build.sh) to create AMIs pre-configured with opengris-scaler.
• Configuration: Added ORBAWSEC2WorkerAdapterConfig for detailed adapter settings. Removed redundant top-level event_loop and worker_io_threads fields — these are now inherited from the standard worker_config.
• Multi-worker support: Each EC2 instance runs cpu_count - 1 workers, where cpu_count is determined by the machine type configured by the user.
• Unified entry points: The ORB AWS EC2 worker manager is fully integrated into scaler_worker_manager (as the orb_aws_ec2 subcommand) and the scaler all-in-one launcher (type = "orb_aws_ec2" in [[worker_manager]]). The dedicated scaler_worker_manager_orb entry point has been removed.
• Scheduler Fix: The WorkerAdapterController now waits for a pending command to complete before sending a new one, preventing duplicate StartWorkerGroup commands during the long ORB polling period.

Bug Fixes

• TooManyWorkers suppression during EC2 boot: The suppression logic was inverted, causing the scheduler to resume spamming StartWorkers immediately after receiving TooManyWorkers. Replaced the Set-based approach with a baseline Dict that records the managed worker count at the time TooManyWorkers was received — suppression is now held until at least one booting instance registers.
• Zero-worker default on single-core machines: DEFAULT_MAX_TASK_CONCURRENCY was cpu_count() - 1, which evaluates to 0 on single-core machines. Removed the subtraction so at least one worker is started by default.
• ORB strategy defaults workaround: When ORBClient is initialised with app_config=, it skips _load_strategy_defaults(), causing RunInstances to be absent from supported APIs. Fixed by including provider_defaults.aws.handlers explicitly in _build_app_config().
• Lazy-import orb: Moved the from orb import ORBClient import inside _run() to defer it until the adapter is actually used, fixing CI test failures when orb is not installed.
• User data updated: EC2 instances now launch workers via scaler_worker_manager baremetal_native --mode fixed, replacing the deprecated scaler_cluster command.

Dependencies

• Added orb-py and boto3 to the orb_aws_ec2 and all extra dependency groups in pyproject.toml

Usage

Workers launched by the ORB AWS EC2 adapter are EC2 instances that connect back to the scheduler over the network. The scheduler address, object storage address, and object storage server must all be externally reachable from those instances (e.g. a private VPC IP or public IP).

# stack.toml

[scheduler]
scheduler_address = "tcp://0.0.0.0:8516"
object_storage_address = "tcp://127.0.0.1:8517"

[object_storage_server]
object_storage_address = "tcp://0.0.0.0:8517"

[[worker_manager]]
type = "orb_aws_ec2"
scheduler_address = "tcp://<scheduler_external_ip>:8516"
object_storage_address = "tcp://<oss_external_ip>:8517"
image_id = "ami-0528819f94f4f5fa5"
instance_type = "t3.medium"
aws_region = "us-east-1"

scaler stack.toml
# or
scaler_worker_manager orb_aws_ec2 tcp://<scheduler_external_ip>:8516 \
    --object-storage-address tcp://<oss_external_ip>:8517 \
    --image-id ami-0528819f94f4f5fa5 \
    --instance-type t3.medium \
    --aws-region us-east-1