IBX-12029: Added content publication strategy contract with synchronous default strategy

[bnowak]

🎫 Issue	IBX-12029

Related PRs:

• https://github.com/ibexa/async-content-publishing/pull/6

Description:

Introduces Ibexa\Contracts\Core\Repository\Strategy\Publication\ContentPublicationStrategyInterface as the single entry point for publishing a content version, hiding whether publication happens synchronously (in-request) or asynchronously (queued background work, provided by the ibexa/async-content-publishing package).

Key decisions:

• Strategies are tagged services (ibexa.repository.content.publication_strategy); ChainContentPublicationStrategy — aliased to the contract — executes the first strategy whose supports() returns true, in priority order. Follows the existing ContentValidatorStrategy/RenderStrategy pattern.
• SynchronousContentPublicationStrategy is the always-applicable fallback (priority -100); it delegates to ContentService::publishVersion(), so behaviour on this path is identical to today.
• Selection happens at runtime, per request — not at container build time. In multi-repository installations the async_content_publish flag can be enabled for some repositories and disabled for others; a compile-time alias swap cannot honour that, while a runtime supports() check (backed by RepositoryConfigurationProviderInterface) routes each repository correctly.

No behaviour change: nothing consumes the strategy yet (switching the publish entry points, e.g. content-forms, is a follow-up task), and without the async package installed the chain contains only the synchronous strategy.

For QA:

No user-facing change in this PR — the strategy is not consumed by any UI flow yet. Covered by unit tests (tests/lib/Repository/Strategy/Publication). Container wiring can be inspected with bin/console debug:container --tag=ibexa.repository.content.publication_strategy (synchronous strategy registered at priority -100, contract aliased to the chain).

Documentation:

Nothing to document yet — client-facing behaviour is unchanged. Documentation will accompany the asynchronous content publishing feature (IBX-11780).

[Steveb-p]

Is this functionality supposed to be already injected into ContentService? I don't see any changes to it's publish version, so I assume this is just new classes that aren't enabled yet in core?

[konradoboza]

I think it's described:

No behaviour change: nothing consumes the strategy yet (switching the publish entry points, e.g. content-forms, is a follow-up task), and without the async package installed the chain contains only the synchronous strategy.

[bnowak]

Is this functionality supposed to be already injected into ContentService? I don't see any changes to it's publish version, so I assume this is just new classes that aren't enabled yet in core?

not yet, that will be part of 2 next (tiny) PRs to start using it.
This part is about introducing a consistent entrypoint for content publishing. 😉

[Steveb-p]

Is this functionality supposed to be already injected into ContentService? I don't see any changes to it's publish version, so I assume this is just new classes that aren't enabled yet in core?

not yet, that will be part of 2 next (tiny) PRs to start using it. This part is about introducing a consistent entrypoint for content publishing. 😉

Sounds good. Technically I'd argue that that next PR should be already included here, because otherwise it's basically dead code that isn't doing anything until that other PR is added. But I'll look the other way :)

[bnowak]

Is this functionality supposed to be already injected into ContentService? I don't see any changes to it's publish version, so I assume this is just new classes that aren't enabled yet in core?

not yet, that will be part of 2 next (tiny) PRs to start using it. This part is about introducing a consistent entrypoint for content publishing. 😉

Sounds good. Technically I'd argue that that next PR should be already included here, because otherwise it's basically dead code that isn't doing anything until that other PR is added. But I'll look the other way :)

Indeed, currently it's dead code - the same as the whole async-content-publishing package.

Next PRs, will be spread across 2 (or more) other packages, so it would be hard to include them here 😅 (just joking). Right now, I'm discovering new dependencies that (I guess) need to be handled, but I'm researching them at the moment. This PR is independent of how many further places/processes will be using it. I prefer a baby-steps approach (in logical parts) and don't put the whole implementation into a single PR, also for shorter and faster reviews 😉

However, I see your point to have the full flow covered/addressed in one PR/sets of PRs. Next set of PRs will end the loop, I promise 😉

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[alongosz]

Nothing to QA yet, API covered by unit tests. Merging.