feat(telemetry): anonymous daily installation heartbeat

[basb7]

What does this change?

Flagward is self-hosted, so today there is no way to know how many installations exist, which versions they run, or whether multivariate flags and the SDK adapters are actually used. This adds an anonymous, aggregate-only, opt-out daily heartbeat from each installation.

What is sent: version, runtime (Python/Django, Docker or not, database, Redis, email configured), counts (orgs, projects, environments, active users, flags by type, rules, rollouts, variants, active overrides), active SDK types/versions per environment, and a bucketed 24h evaluation volume. Plus mode (production/development) and server (asgi/wsgi/runserver), so prod and dev installs are counted separately.

What is never sent: emails, names, flag keys, variant names, condition values, API keys, hostnames. sdk_type/version are client-supplied free text, so they are mapped to an allowlist (other/unknown). Every field is listed in docs/telemetry.md.

When it is on

• Unset FLAGWARD_TELEMETRY → on, in production and development alike, except when CI is truthy.
• FLAGWARD_TELEMETRY=false → no thread, no DB row, no network request.
• compose.dev.yml forwards CI into the backend container; without it the e2e job would report itself as a dev install on every run.

How it works

• telemetry.InstallationIdentity: a singleton row (DB-enforced) with a random UUID4.
• Started from config/asgi.py / config/wsgi.py, never from AppConfig.ready(), so migrate, tests and other commands never spawn it.
• Every worker runs a daemon thread (30–300s jitter, then hourly). A conditional UPDATE ... WHERE last_sent_at < now-24h lets exactly one worker per window send. Claim-then-send: a failed send is not retried until the next window.
• stdlib urllib, 3s timeout, every failure swallowed and logged at DEBUG only.
• Fixed destination: always https://telemetry.flagward.com/v1/heartbeat (telemetry.settings.TELEMETRY_URL). Operators can turn it off, not redirect it — there is exactly one place the data can go, and it is public.
• manage.py telemetry --show prints the exact payload without sending; --send sends now.
• Adds config/version.py (__version__, bumped per release): operators build from source, so a Docker build arg would be empty. Adds a minimal LOGGING for the telemetry logger, since Django's default config would swallow the startup notice.

The collector is live

basb7/flagward-telemetry is deployed at telemetry.flagward.com: strict schema v1, one row per installation per day, Nginx strips the client IP before the app and keeps no access logs, and the public page publishes only per-installation aggregates with a minimum group size of 5.

How was it verified?

• 117 new tests (803 total): opt-out truth table, schema v1 key set pinned independently of the builder, a privacy test seeding recognizable strings (secret-launch, Acme, ana@acme.com, the API key) and asserting none leak, slot dedup, failure isolation, --show never creating the identity or reaching the network, and a clear error on an unmigrated DB.
• Manually, with Docker and a local stub (before the destination was fixed):
  • compose.dev.yml → payload with mode=development, server=runserver; identity stable across restarts
  • CI=true → --send reports disabled, no startup notice, nothing received
  • compose.yml (4 workers) → 4 startup notices, exactly one payload, mode=production, server=asgi; restart within 24h → nothing
  • FLAGWARD_TELEMETRY=false → no notice, nothing received
  • collector down → no errors in logs, /api/v1/health/ still 200
• End to end against the collector running locally in Docker (production stack, before deploy): a heartbeat from the Docker install reached it with 204, and a second one the same day kept a single row.
• The destination test asserts the URL ignores any environment variable and is not a Django setting.

Checklist

• Tests added or updated for this change
• ruff check . passes
• pytest passes
• npm run lint and npm run build pass, if the frontend changed — frontend unchanged
• Documentation updated, if behaviour changed
• Commits follow Conventional Commits