feat: keep the tenant's configuration in Git with export --tenant

[achoimet]

export/diff/apply kept one team in Git (experiments, schedules, services, profiles). Admins want the tenant's configuration there too. This is the use case on the Kanbanize card: automating templates and experiments.

steadybit export --tenant -d ./platform   # templates, environments, teams, property definitions, hubs, integrations, custom service profiles
steadybit diff -d ./platform              # exit 2 on drift
steadybit apply -d ./platform --dry-run

Layout and order

• One directory per kind: property-definitions/, environments/, teams/, hubs/, templates/, integrations/{webhook,slack,preflight,preflight-action}/, service-profiles/. --team and --tenant are mutually exclusive.
• Each file is what the kind's get writes; each package's read-only list is reused.
• diff -d / apply -d handle whichever directories exist, in one dependency order:
  1. property definitions
  2. environments
  3. teams (they name environments)
  4. hubs
  5. templates (service profiles name them)
  6. integrations
  7. service profiles
  8. services
  9. experiments
  10. schedules
• Each new kind also gets its own diff and apply --dry-run.
• Matching, checked on dev:
  • environments by id, else by name (the platform upserts by name);
  • teams by key;
  • property definitions by key;
  • templates, hubs and integrations by id.
• Left out:
  • the hubs the platform connects itself;
  • templates imported from a hub (template import brings them back);
  • Steadybit's provided service profiles;
  • property associations, which belong to a team's experiments and services.

Secrets. Verified on dev and in the platform source:

• On read, the platform masks secret with one * per character. Sending that mask back is refused with 422. Leaving the secret out deletes it.
• Header values and Slack webhook URLs are returned in the clear.

So:

• Exported files hold '********' for every credential: the secret, every header value, and the Slack URL.
• In diff, a mask matches whatever the platform holds, so a fresh export shows no drift. A credential is never printed: a real one from the file shows as '******** (from the file)'.
• apply -d skips integrations that match the platform. For a changed one, masked headers and the Slack URL are restored from what the platform holds. A masked secret is refused, with a message pointing at get/export.

Defaults (see #70):

• A field left as an empty list or map now counts as its default too.
• Teams default to allowedActions: [wait, service-validation] and managedBy: MANUAL, webhooks to targetAttributeIncludes: ['*'].
• Members' name, pictureUrl and managedBy are read-only.

Testing

• Unit tests with the fake platform, covering:
  • export contents byte for byte;
  • provided items excluded, imported templates never fetched;
  • an export diffing clean;
  • apply skipping matching integrations and keeping the order;
  • masked Slack URLs and headers filled in;
  • credentials never printed;
  • team and webhook defaults, with a real difference still reported;
  • an environment found by name.
• go test -race ./... and go vet (also GOOS=windows) pass.
• Reviewed on dev:
  • export --team W writes byte-identical files with main and with this branch;
  • export --tenant wrote 272 templates, 45 environments, 31 teams, 23 property definitions, 1 hub, 11 integrations and 12 service profiles;
  • no Slack URL and no unmasked header value appears;
  • diff -d on that export: every file matches, exit 0.
• Apply, on resources the agent created only (cli-e2e-export-*, team CLIX, URLs on example.com, all deleted afterwards):
  • export → diff clean → apply updated everything and skipped the integrations;
  • the webhook secret was still stored afterwards;
  • editing the Slack channel and the webhook events showed only those changes;
  • apply refused the masked webhook secret; with the secret put in it succeeded, and the Slack URL was kept.

Not verified: applying an export to a different platform, where the ids don't exist. It's unknown whether the platform creates templates, hubs and integrations under the id it is sent. Also untested: OIDC-managed teams with members.

Open questions

1. Mask every header value (safe, but hides harmless ones in Git), or only credential-like names?
2. An integration file with its real secret filled in always shows as a difference, because the platform can't confirm a secret. Acceptable for drift checks?
3. Include custom service profiles in the tenant export, as now?
4. The tenant export is sequential and takes about 3 minutes on dev. Should it fetch in parallel?

The CHANGELOG v6.1.0 section will conflict trivially with the other open feature PRs.