Reconsider our approach to OSS vs. commercial builds

We've tried to setup our CI so that it is as close as possible between OSS builds and enterprise support builds, using a single spring.build-type switch.

After a lot of iterations, the build itself seems to work (although it could break without us noticing until the next branch enters commercial support). However, CI never did.

Promote release requires "sync to maven central" to complete but it will not with a commercial build:
https://github.com/spring-projects/spring-boot/blob/3754efb40791baaf327254f87044fd51464f3232/.github/workflows/release.yml#L82-L86

Same for the publication of the release notes that depends on a number of steps that must be skipped for commercial builds:
https://github.com/spring-projects/spring-boot/blob/3754efb40791baaf327254f87044fd51464f3232/.github/workflows/release.yml#L160-L168

Diffing .github between 3.3.x and 3.4.x can adapt CI pretty easily. Yes, it is a manual step but it also helps with long maintenance and simplify the build greatly.

I think we should revisit our decision. Introducing consistent variables and secrets could help reducing the noise to a bare minimum.

Here is an example where the if/else dance could go away with a consistent variable name:
https://github.com/spring-projects/spring-boot/blob/3754efb40791baaf327254f87044fd51464f3232/.github/workflows/release.yml#L92

Start with .github/workflows/release.yml, especially the referenced lines around Maven Central synchronization, release notes publication, and the example near line 92. Compare the .github directories between 3.3.x and 3.4.x; done means commercial and OSS release workflows use consistent variables or secrets while skipping steps that do not apply to commercial builds.