Upgrade job: enable the CDN flag on all channel-type drives

[toddmitchell]

Summary

Add a version upgrade job (v16 → v17) that turns on the AllowCdn flag for every drive of type SystemDriveConstants.ChannelDriveType (8f448716-e34c-edf9-0141-45e043ca6612).

Why

AllowCdn is opt-in per drive (StorageDriveDetails.AllowCdn, surfaced via StorageDrive.IsCdnEnabled()), and the only drive seeded CDN-on is PublicPostsChannelDrive (SystemDriveConstants.CreatePublicPostsChannelDriveRequest). Channel drives created by the owner before the flag existed — and any channel drive created since without AllowCdn set — are invisible to the CDN grant path (CdnAuthPathHandler builds its grant set from IDriveManager.GetCdnEnabledDrivesAsync). Channel content is exactly what the CDN exists to serve, so those drives should be enabled.

Proposed implementation

Follow the existing per-version migration pattern (see Version15tov16/V15ToV16VersionMigrationService.cs):

1. New src/services/Odin.Services/Configuration/VersionUpgrade/Version16tov17/V16ToV17VersionMigrationService.cs
   • UpgradeAsync: driveManager.GetDrivesAsync(SystemDriveConstants.ChannelDriveType, PageOptions.All, odinContext), then SetDriveAllowCdnAsync(drive.Id, true, odinContext) for each drive where IsCdnEnabled() is false. SetDriveAllowCdnAsync is already a no-op when the value is unchanged and publishes DriveDefinitionAddedNotification, so it's safe to call per drive.
   • ValidateUpgradeAsync: re-read channel drives and throw OdinSystemException if any still has IsCdnEnabled() == false; optionally log the count returned by GetCdnEnabledDrivesAsync.
   • Requires master key — the upgrade context already carries it (odinContext.Caller.AssertHasMasterKey()).
2. Register in src/apps/Odin.Hosting/TenantServices.cs alongside V15ToV16VersionMigrationService (line ~408).
3. Add the currentVersion == 16 block in VersionUpgradeService.UpgradeAsync (stacked transaction → UpgradeAsync → ValidateUpgradeAsync → IncrementVersionAsync → commit).
4. Bump Version.DataVersionNumber to 17 (src/services/Odin.Services/Version.cs).
5. Test in the style of tests/apps/Odin.Hosting.Tests.V2/Ported/... migration tests (e.g. V11ToV12ChatAppMigrationTests): create a channel drive with AllowCdn = false, run the migration, assert the drive comes back CDN-enabled and that a non-channel drive was left alone.

Open questions / decisions

• Scope of "all channel drives" — should owner-only or non-anonymous channel drives be included, or only AllowAnonymousReads ones? SetDriveAllowCdnAsync deliberately has no system-drive / owner-only guard, so the migration can flip them; whether it should is a product call. Default proposal: flip all drives of the channel type, since the flag only grants CDN read and channel drives are content drives by definition.
• Idempotency / new drives after upgrade — this is a one-shot backfill. If channel drives should always default to CDN-on, drive creation should also default AllowCdn = true for ChannelDriveType; otherwise drives created after the migration will again be CDN-off. Worth deciding in the same change.
• Collaborative channels — drives with BuiltInDriveAttributes.IsCollaborativeChannel are still channel-type; confirm they're intended to be included.

---

Verified by reading code: AllowCdn is opt-in per drive, PublicPostsChannelDrive is the only system drive seeded CDN-on, ChannelDriveType exists and GetDrivesAsync(type, ...) / SetDriveAllowCdnAsync / GetCdnEnabledDrivesAsync are the relevant APIs, and the v15→v16 migration + VersionUpgradeService + TenantServices registration form the pattern to copy. Not verified: how many real deployments actually have CDN-off channel drives, and whether the CDN edge/ops side needs any corresponding config change — that lives outside this repo.