Apply nginx rules for next gen images

[wordpressfan]

Description

Fixes #821

Documentation

User documentation

Here we are playing with rewrite rules so users need to reload their nginx after upload to get those new rules being applied.

Technical documentation

Here I used the webp class to write the next gen handling rewrite rules so we don't need to run any code with plugin update to remove the old rules and insert the new ones, as I think those webp rules were already there in previous versions.

Also I kept avif rewrite rules empty to unify the code structure and keep it as currently used, but it's not added to the config file at all because it's empty.

If you think this would be confusing having the comment Imagify: rewrite rules for webp let me know and I can check how to do this upgrade routine here in imagify.

Type of change

Delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue).

New dependencies

List any new dependencies that are required for this change.

Risks

List possible performance & security issues or risks, and explain how they have been mitigated.

As mentioned above we have two risks:

1. We need to tell users to restart their nginx once our rules are changed, maybe we can use admin notices or add this to our documentation in a clear way.
2. We need to check if the comment in config file is confusing or it;s OK to have Imagify: rewrite rules for webp but it's handling webp and avif.

What do u think @piotrbak ?

Checklists

Feature validation

• I validated all the Acceptance Criteria. If possible, provide sreenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Documentation

• I prepared the user documentation for the feature/enhancement and shared it in the PR or the GitHub issue.
• The user documentation covers new/changed entry points (endpoints, WP hooks, configuration files, ...).
• I prepared the technical documentation if needed, and shared it in the PR or the GitHub issue.

Code style

• I wrote self-explanatory code about what it does.
• I wrote comments to explain why it does it.
• I named variables and functions explicitely.
• I protected entry points against unexpected inputs.
• I did not introduce unecessary complexity.
• I listed the introduced external dependencies explicitely on the PR.
• I validated the repo-specific guidelines from CONTRIBUTING.md.

Observability

• I handled errors when needed.
•  I wrote user-facing messages that are understandable and provide actionable feedbacks.
• I prepared ways to observe the implemented system (logs, data, etc.).

Risks

•  I explicitely mentioned performance risks in the PR.
• I explicitely mentioned security risks in the PR.

[jeawhanlee]

Shouldn't we update the value of the class const TAG_NAME to be generic?
Don't we also need to move it out of the Webp namespace?

[remyperona]

I agree it feels weird to do it like this

[wordpressfan]

I mentioned that in the PR description (risks part) but let me explain this in details, the idea here is, currently our customers have old webp rules and if I understand this part well, we are detecting those rules by this tag name, so if I changed this tag name without adding an update routine to completely remove the old rules, we will end up having two rules, something like the following:

# BEGIN Imagify: rewrite rules for webp
OLD RULES
# END Imagify: rewrite rules for webp

# BEGIN Imagify: rewrite rules for nextgen
NEW RULES
# END Imagify: rewrite rules for nextgen

but if we kept it as webp we will not need this update routine.

If u think that would be confusing/weird we can have this update routine.

[jeawhanlee]

Should we still keep this class?

[wordpressfan]

I already mentioned this also in the PR description :D
to keep the structure consistent, I kept it.
But let's think about this together.

[remyperona]

this should not be added, it's causing bugs in some cases (we already reverted it in a previous PR)

[wordpressfan]

Many thanks, going to remove it then, wasn't aware of this previous PR.

[remyperona]

I agree it feels weird to do it like this

[Mai-Saad]

Rules applied correctly on apache, local and imagify.rocketlabs.

Note: on https://imagify.rocketlabsqa.ovh/ if we uploaded the zip file of any plugin, we will have error in media library (may needs further investigations when documenting changes needed at nginx server) => without playing with nginx rules at newer.rocketlabsqs upload plugin zip is fine