Add support for queueing invalidations

The motivation is good, however the implementation needs work

This issue is really interesting, thanks for the contribution @kevinb623 . Supporting queues may drastically improve the performance when there are too many URLs to purge.

Also many thanks for helping reviewing @dpi, it saved me time.

The most priority changes needed to merge this are:

1. Make form labels translatable
2. Hook install to configure existing sites.
3. Coding standards must pass, Currently, this module is integrated with Gitlab CI to help on this purpose.
4. Ideally, applying every suggestion mentioned in the feedback.

I thing this is going the wrong direction. Purge API is not being used the right way by the module and thus, by this MR.

Some things I've seen so far:

Regarding the general module implementation

1. The user should not need to choose a processor

Choosing a processor is useless. Despite the processor, it will purge files on the fly when invoking the hook in the middle of the request (not on cron, not on late runtime). Purge's invalidate() requires a processor indeed, but it is not used at all. See https://git.drupalcode.org/project/purge/-/commit/a3632d03ee72b0a09aa1b2...

Instead of processing invalidations on the fly, it should rely on a queue and the system-wide configured processor. Otherwise, on any failure, we're exposed to lose pending invalidations since they're not tracked.

If immediate purge were necessary for some reason, it could be opt-in in the module configuration. This should show a warning message, and not rely on the user choosing a processor, but passing invalidate() any of the enabled processors since it is a required parameter although useless.

2. The module should warn and inhibit, if no url (or wildcardurl) invalidator processor is available.

It passes silently if no compatible invalidator is enabled.

Regarding this MR

1. Purge queue is mandatory in purge configuration.

No need to choose a queue.

2. To enqueue items implement a PurgeQueuer plugin and use @purge.queue service

There's an implementation easy to follow in this module: https://git.drupalcode.org/project/url_purge_aggregator/-/tree/1.x/. See https://git.drupalcode.org/project/url_purge_aggregator/-/blob/1.x/url_p...

@jonhattan Regarding "Purge API is not being used the right way by the module and thus, by this MR.", that is your opinion.
The settings form for the purge_file module follows what would be expected by a Drupal contrib module that implements a plugin system - select a plugin that affects the system. However, the purge module's plugins actually do not do anything other than provide labels for log messages. For example - In \Drupal\purge\Plugin\Purge\Queue\QueueService::add(QueuerInterface $queuer, array $invalidations)>code>, the <code>$queuer argument is meaningless and is only used for the log message.

public function add(QueuerInterface $queuer, array $invalidations) {
    foreach ($invalidations as $invalidation) {
      if (!$this->buffer->has($invalidation)) {
        $this->buffer->set($invalidation, TxBuffer::ADDING);
      }
    }
    $this->logger->debug("@queuer: added @no items.", [
      '@queuer' => $queuer->getPluginId(),
      '@no' => count($invalidations),
    ]);
  }

Another example is the processor plugin. The purge module's own submodule purge_processor_cron implements its own hook_cron and then just passes the "cron" plugin to \Drupal\purge\Plugin\Purge\Purger\PurgersService::invalidate(ProcessorInterface $processor, array $invalidations)<code> which the <code>$processor argument is never used, any code validation would detect it as "unused".

Any plugin for the purge module's system does not do anything without additional custom code.
So one might ask the alternate question - why does the purge module even have plugins?

I created a new branch 3400166-use-purge-api (MR 10) that extends the original updates in MR 6 and refactors to use the purge plugins and API.

• Implements its own purge plugins for a queuer and processor
• There is only a selection for the new "Workflow", eliminating the selection for a queuer and processor since that is no longer needed.
• Added warnings on the settings page and status report regarding supported URL purgers.
• Updated the module code to support the new workflows.
• Added an update function to convert the old configuration to the new configuration

Attached is a static patch of MR10 for composer builds.

The MR !10 looks fine.

About the feedback from #7, this module has born as a solution to inmediate purge files, as a project was needing to instantly refresh its financial reports / legal documents after replacing those files having the same. Purge allows it but do not recommend it https://git.drupalcode.org/project/purge#api-examples . In the practice , inmediate purge is working fine. Edit: this additionally let's the file purging has a different processing that general purge of pages that may be updated with the available processors and queuers, as the phase of purging may differ for this specific use case.

It is true that not every site needs an inmediate purge, and there are sites where inmediate purging every update file on a page may lead to performance issues. That's why this contribution is very valuable for the project, letting developers to choose the best option for their sites.

After reviewing it, it works fine. The hook update provides the backwards compatibility and it additionally fixes some problems on the hook_requirements. I've merged it and I will create a release right now.

Merged and released at 1.2.0. Thanks all for the help and feedback!