[Core] Reindex refactoring for Engine

[alexander-schranz]

The EngineInterface currently a reindex method which looks like this, the method design was choosen because we don't want to create an instance of reindexProviders if the Engine is only used for search:

/**
 * @param iterable<ReindexProviderInterface> $reindexProviders
 * @param callable(string, int, int|null): void|null $progressCallback
 */
public function reindex(
    iterable $reindexProviders,
    ReindexConfig $reindexConfig,
    callable|null $progressCallback = null,
): void;

This is sadly very differently as all other methods which we currently have on the Engine itself as reported by @Toflar in #603.

So maybe something more on the common reindex(string $index, ...) would be better pattern:

public function __construct(
    private readonly AdapterInterface $adapter,
    private readonly Schema $schema,
    private readonly iterable $reindexProviders = [],
) {
}

/**
 * @param iterable<string> $identifiers
 * @param callable(string, int, int|null): void|null $progressCallback
 */
public function reindex(
    string $index,
    array $identifiers = [],
    callable|null $progressCallback = null,
): void;

/**
 * @param iterable<string> $identifiers
 * @param callable(string, int, int|null): void|null $progressCallback
 */
public function reindexAll(
    callable|null $progressCallback = null,
): void;

@Toflar was this the interface you where thinking of?

---

We sure need to have a look how to implement the lazy mechanic in other framework integrations which do not like Symfony support lazy services so maybe with additonal LazyReindexProviderCollection e.g. for Yii maybe something like:

new Engine(
    $adapter,
    $schema,
    new LazyReindexProviderCollection(function() use ($container, $reindexProviderNames) {
        foreach ($reindexProviderNames as $reindexProviderName) {
            yield $container->get($reindexProviderName);
        }
    }),
);

Expected BC Breaks

This change would include BC Breaks and so should be tackled before the 1.0 release:

• Engine / EngineInterface Reindex method and constructor
• Reindex Commands constructor

[Toflar]

Yes. I would probably still use a ReindexConfig (that contains also the optional progress callback) so that it can be easily extended with new configuration without breaking the API again 😊