[Feature]: Support storage and services in catalog workloads

[mrhillsman]

Problem Statement

Catalog workloads (GenericWorkload and GenericMultiWorkload) currently inherit BaseWorkload defaults for all storage and service methods:

• ExtraVolumes() → nil
• ExtraDisks() → nil
• DataVolumeTemplates() → nil, nil
• RequiresService() → false
• ServiceSpec() → nil

This means users who want to add a workload via the catalog system cannot use persistent storage (DataVolumes, extra disks) or K8s Services without writing Go code and rebuilding the binary. Workloads like disk, database, and network all require these features, so their catalog equivalents are currently not possible.

Proposed Solution

Extend the workload.yaml manifest schema to support declarative storage and service definitions. For example:

storage:
  - name: data
    size: 10Gi
    serial: virtwork-data
    mount: /mnt/data

service:
  ports:
    - name: iperf
      port: 5201
      protocol: TCP
  selector-role: server

GenericWorkload and GenericMultiWorkload would then override the relevant BaseWorkload methods based on these manifest declarations, using the same patterns as the built-in storage-backed workloads (vm.BuildDataVolumeTemplate, serial-based device discovery, diskSetupScript).

Alternatives Considered

• Status quo — document that catalog entries cannot use storage or services, and direct users to implement built-in workloads for those cases. This is the current approach in docs/development.md.
• Hybrid approach — allow catalog entries to reference a Go "mixin" or plugin for storage/service behavior, keeping the service file authoring in the catalog but the infrastructure wiring in Go.

Area

• Workloads

Architecture Layer

• Layer 3 - Workload Definitions (workloads, registry)

Additional Context

The catalog system was introduced to let users add workloads without modifying Go code. Storage and service support would close the remaining gap between catalog and built-in workloads. The built-in patterns in disk.go, database.go, and network.go are well-established and could serve as reference implementations for the generic versions.