Standardize bundle output names; hard-error on profile output: patterns

[cotti]

Why

Bundle output names are being standardized by convention ({product}-{version}.yaml) so every consumer — the scrubber, the CDN registry, the promotion workflow, backfill — can derive a bundle's location from product + version alone (RFC B2, closes #3774). Explicit output: patterns in profiles undermine that and, silently, let two profiles overwrite each other's target.

What

• Bundle names derive from the profile's primary output product (first product in output_products, else products) and the version argument, in both the run and --plan (the CI bundle-create action locates the file via plan output). Invocations without a resolvable product/version (e.g. report-only) keep the changelog-bundle.yaml default.
• Setting output: on any profile is now a hard error with a message directing removal; the field stays parseable for one release cycle so authors get the error rather than a YAML parse failure.
• Two profiles sharing a primary output product are rejected — they would resolve to the same conventional target for any given version.
• Example config, reference docs, and the affected test fixtures migrated to the convention.

Breaking: repositories with output: in changelog.yml profiles must remove it; their bundle file names change to the convention on the next cut.

Stack: 3/5.

[Mpdreamz]

also add `[Obsolete()] maybe?

[cotti]

Done in 6ac9142 — added [Obsolete] with a message pointing at the convention, and suppressed CS0618 at the two intentional read sites (loader + hard-error validation) since warnings are errors here.

[lcawl]

Bundle output names are being standardized by convention ({product}-{version}.yaml) so every consumer — the scrubber, the CDN registry, the promotion workflow, backfill — can derive a bundle's location from product + version alone

I think this is problematic since we have multiple repos contributing to the same products and their releases could occur on the same day (e.g. any of the repos putting bundles into https://us-east-1.console.aws.amazon.com/s3/buckets/elastic-docs-v3-changelog-bundles?region=us-east-1&prefix=bundle/cloud-serverless/&showversions=false could occur on the same day, which is why we currently name them based on the repo they're derived from). Ditto for https://us-east-1.console.aws.amazon.com/s3/buckets/elastic-docs-v3-changelog-bundles?region=us-east-1&prefix=bundle/cloud-hosted/&showversions=false where you have bundles dropping from multiple repos potentially on the same day for ECH releases.

Perhaps this means you need to change the pattern to {repo}-{product}-{version}.yaml?

Breaking: repositories with output: in changelog.yml profiles must remove it; their bundle file names change to the convention on the next cut.

Even if you don't allow teams to specify their filename, I think you might need to keep it around just for the folder path (and test it, not sure if a folder alone is currently accepted). For example, in the case where we're publishing from bundles that exist locally in the repo and we have multiple pages that relate to different products (e.g. Serverless and Observability and Security in docs-content or ECE and ECH in cloud), the changelog directive pulls all the bundles from a specified path (i.e. profiles need to route bundles to specific paths, which is currently accomplished by prepending a path to the filename in the output setting). I don't think you can get away from that until you get to the point where you stop storing and publishing bundles locally.