[DEV] Add Quadlet configuration and RPM packaging

[alexlovelltroy]

Goal

Prepare metadata-service to be distributed as a standalone RPM as part of an OpenCHAMI release.

Today, its Quadlet and RPM packaging are maintained centrally in the OpenCHAMI/release repository. Move ownership of the service-specific deployment artifacts into this repository while continuing to consume shared OpenCHAMI infrastructure from the release/common packages.

This work complements #25.

Scope

• Add and maintain the metadata-service.container Quadlet in this repository.
• Add and maintain the metadata-data.volume Quadlet, or document why it belongs in a shared package.
• Add an RPM spec that installs the service-owned Quadlet files into /etc/containers/systemd/.
• Derive the RPM version from the metadata-service release/tag and document the package naming and version mapping.
• Add a reproducible local build target and CI validation for the RPM.
• Document installation, configuration, upgrade, and removal behavior.
• Document all required environment variables, secrets, capabilities, devices, volumes, and service dependencies.

Current deployment requirements to preserve

The current release configuration includes the following metadata-service requirements:

• Container image: ghcr.io/openchami/metadata-service
• Shared environment file: /etc/openchami/configs/openchami.env
• TokenSmith bootstrap token exposed as TOKENSMITH_BOOTSTRAP_TOKEN
• Token bootstrap through /usr/sbin/tokensmith_bootstrap_token metadata-service
• SMD and TokenSmith service dependencies
• metadata-service-data persistent volume mounted at /data
• openchami-internal.network
• /dev/net/tun and CAP_NET_ADMIN for WireGuard tunnel creation
• --http-proxy=false
• Membership in openchami.target

Use the current files in OpenCHAMI/release as migration inputs, not necessarily as the final design. Remove accidental duplication while porting them, such as repeated secret declarations.

Shared-package boundary

Do not duplicate shared deployment infrastructure in this repository. The RPM should declare or document dependencies on the package that owns shared artifacts such as:

• openchami.target
• openchami-internal.network
• /etc/openchami/configs/openchami.env
• TokenSmith bootstrap tooling
• repository-wide certificate and bootstrap scripts

Acceptance criteria

• The RPM builds successfully in CI and locally using documented commands.
• Installing the RPM places only metadata-service-owned files in their expected locations.
• systemctl daemon-reload discovers the generated metadata-service unit.
• The installed Quadlet starts metadata-service successfully with its required network, volume, secret, and WireGuard permissions.
• Package dependencies on shared OpenCHAMI infrastructure are explicit.
• Upgrade and uninstall behavior preserve operator-managed configuration and persistent metadata.
• The standalone RPM can be consumed by an OpenCHAMI meta-package.

RPM signing

Use OpenCHAMI/gpg-signing-manager as the source of truth for RPM signing. Do not create another signing implementation or use the stale duplicate signing actions under OpenCHAMI/github-actions.

• Use the signing-manager ephemeral-key and RPM-signing workflow established by OpenCHAMI/release.
• Pin referenced signing actions to immutable commit SHAs rather than @main.
• Verify the completed package with rpm --checksig before publication.
• Keep signing credentials in protected GitHub secrets/environments; do not commit or package private key material.
• Publish the required public verification material alongside the signed RPM.