IBX-1694: Implemented Symfony Service Tag compatibility layer

[alongosz]

Question	Answer
JIRA issue	IBX-1694
Type	feature
Target Ibexa version	v4.0
BC breaks	no

This PR adds compatibility layer for the legacy eZ Platform Symfony Service Container Tag names, defining the mapping between old names and new Ibexa names.

The solution is to find all legacy tags and add another tag with the new name and the same attributes. Legacy tag names are not removed from the definitions due to BC. Even if we ourselves remove old tags, there's no way to know if some 3rd party still relies on them.

• What needs to be discussed here are the new naming choices made here. Grouping is done by the dots (.) in the new tag names, but groups are related to domain/functionality rather than a package defining the tag. If there's a certain pattern associated with a tag (e.g.: visitor, handler), it is placed at the end of a name.

Naming convention

ibexa.<domain>.[adapter].<specifics>.[design_pattern]

where <specifics> may or may not be grouped (aiming not to group) per case basis. If a group can be identified for certain items, it should be used. [] implies optional part.

Previously deprecated tags

The support for Tags that were deprecated in Ibexa 3.3 or earlier is going to be dropped. They're not included in the map. Some leftover usages will be replaced across the codebase with the new name.

• ezpublish.searchEngineIndexer
• ezpublish.searchEngine
• ezpublish.fieldType.externalStorageHandler
• ezpublish.fieldType.externalStorageHandler.gateway
• ezpublish.fieldType
• ezpublish_rest.field_type_processor
• ezpublish.fieldType.parameterProvider
• ezpublish.storageEngine.legacy.converter
• ezpublish.fieldType.indexable
• ez.fieldFormMapper.definition
• ez.fieldFormMapper.value

TODO

• Update mapping with all needed tags
• Add minimal test coverage

Checklist:

• Provided PR description.
• Tested the solution manually.
• Provided automated test coverage.
• Ran PHP CS Fixer for new PHP code (use $ composer fix-cs).
• Asked for a review

[alongosz]

@konradoboza #12 (review) resolved via 914caf7. Thanks!

[konradoboza]

Yet to be discussed, but it feels like we should go either with . or _ as a separator in general. Having one specific pattern would speed up the process as end developers won't be bothered with any conventions at all while tagging. Determining what should "go together" in naming is relative, it feels like we would benefit from a rule of thumb here. Despite documenting this change I think it will be easier to just assume, that one rule is reused across the system and it's safe to follow it whenever service tags are applied.

[konradoboza]

The convention is still a little bit blurry to me, but the general naming looks fine. Few concerns:

[alongosz]

Update: fc42c63: removed ezsystems.platformui.application_config_provider from the map as it seems to be an unused leftover from v1.x. There are tagged services (#12), but tag itself is not processed anywhere.