Support case-sensitive redirects

This functionality seemed to be important enough to be included in the main module. My site doesn't use the redirect_domain sub module, so I created MR !102 working towards a main module solution.

Next steps:

1. Manual testing
2. Review/fix pipeline issues
3. Write tests

I opted to set the new config value to false if the module is newly installed, but to true if the module is being updated. This is because a site could have mixed-case aliases and redirects and I don't want it to break functionality. I guess this isn't completely foolproof because a site can have aliases before enabling this module.

Thinking "out loud"

An additional feature when toggling the case-sensitivity off or updating the module might be to check if the site does have mixed-case URLs and provide a log message. We could provide a validation error that doesn't allow the user to toggle the option off if there are paths that would be affected. Maybe a batch update feature, if one doesn't already exist.

Made some updates to the update hook because it's not working on my site, but also continues to not work on my site.

The original issue I experienced was an alias was changed, only capitalizing some letters. When this happened, a redirect was created from a completely lowercase version to a mixed-case version and caused a redirect loop.

Aside from the update hook not setting the new config value, my updates do allow for toggling between allowing mixed-case URLs in redirects and aliases and working only with lower case URLs.

Notes

In thinking about possible validation and checking if there are already aliases or redirects with mixed-case, a query like this seems to work:

select * from path_alias where alias regexp binary '[A-Z]';

I would like some input on the direction I'm heading before I add more functionality and tests.

What's the use case for this?

I've just merged 📌 Public method Redirect::generateHash() should unify path before generating the hash Active which would need to be adjusted for this as well.

New config to indicate whether the site allows mixed-case paths or lowercase only. Based on that indicator, we ensure redirects aren't created that cause redirect loops. I think a similar functionality was available in the Drupal 7 version, so I went this route.

I don't know the history of not including it for D8+, so happy to pivot to another path that protects us against redirect loops.

We have a use case for the proposed changes. We have links in the wild that are `/HelloThere`, but `/HelloThere` should also go to `/hellothere`. Making it configurable with the default being case sensitive makes sense to me.

We are using the redirect_domain module portion mostly. so `go.example.com/gohere` and `go.example.com/GoHere` should be the same for our use case.

Found an issue running the tests at the turn of the month for `redirect_404_cron`. Made the compare be `Y-z` instead of `d` because committing code at the turn of the month apparently can cause test failures.

A few comments on the MR.

In addition, I think one big thing that is missing is that when the case sensitivity configuration is changed, all the existing redirects will need to have their hashes re-generated and saved. Right now changing the config probably only affects redirect saves (updates and creates) in the future. There probably needs to be some sort of batch process to act on the existing redirects when the configuration is changed. redirect_update_8100() probably can provide some guidance on what the code to update existing redirects should look like.

I would need that!

My use case: my client asks me to enable filename sanitization for new uploaded files and to sanitize our 50K+ existing files with redirects to keep the SEO juice.

I tried to manually create a Redirect from /sites/default/files/MYFILE.pdf to /sites/default/files/myfile.pdf but when trying to access /sites/default/files/MYFILE.pdf, I get a 503 error because of the RedirectLoopException.

I just rebased the MR so it can easily be applied on the dev branch.
Here is the patch for composer users that would need this fix right now :)

Something went wrong in my previous rebase. Here is the good one and the attached patch file.