Fix #363 - domain and subdomain wildcard

[wikando-ck]

Introduction

Discovered a bug in #363 in resolving private domains that also have a subdomain wildcard.

Proposal

Describe the new/upated/fixed feature

When a rule is added, we check whether a rule-path to it already exists.
If it does and it is the outermost rule ([] === $list[$rule]), we add a special marker which indicates that there is a rule for this part before adding the further path.
The choice of the marker is quite random (?), but it is based on the characters allowed in urls and what is already used in the list entry format.

When resolving the getPublicSuffixLengthFromSection(), before terminating when iteratively matching the domain labels comes to a halt (no more labels to match), before checking whether there are hasRemainingRules() we check for the special marker.
When recursing here, the hasRemainingRules would always be true, as there is another rule further down the array.

I've worked up from adding the special marker for every rule, but that doubled the memory usage from ~2 to ~4MB.
So only adding it, before a new rule is added.
This should always work, due to the right to left sorting.

Backward Incompatible Changes

There should be no BC breaks here.

Targeted release version

6.3.2
I'll verify if i can target older versions.

PR Impact

No API changes
Only the structure of the private rules array is modified slightly.
Fixes a bug

Open issues

to be discussed:

• extracting the checks in addRule into static methods for readability
• choice of marker character

[wikando-ck]

I think backporting to both 6.1 and 6.2 would be possible - please let me if you want to support them and how this would work, as there's no more branches.

[nyamsprod]

I am a bit skeptical at backporting the fix:

• if you are running 6.2 migrating to 6.3 is straightforward the dependencies are the same you will get access to new features and new bugfixes at the same time

• if you are running 6.1 your are most probably on an EOL version of PHP 7.4 and 8.0 (you should not be using those version in production)

Of course this also means that you are using composer and monitoring upgrade on a regular basis.

Now if we backport to 6.1 and not 6.2 it will sound weird 😄

So I would be in favor of just releasing 6.4 with:

• your fix
• the new support for absolute domain aka domain ending with the . from resolving Root domain specifier breaks parser #361

IMHO if you are already on an EOL version of PHP you have bigger problems but I could be wrong.

[nyamsprod]

I see

PR Impact
No API changes
Only the structure of the private rules array is modified slightly.
Fixes a bug

The API is not changed but the structure of the persistence layer is changed. What happened if I download a new version with the fix but I do not update my cached version of the PSL 🤔 (playing the devil advocate)

Whatever the solution I believe tagging a minor is a better solution as with a minor you are telling the developer be careful something may have changed be updated.

[wikando-ck]

I agree, backporting is probably not worth it.

The API is not changed but the structure of the persistence layer is changed. What happened if I download a new version with the fix but I do not update my cached version of the PSL 🤔 (playing the devil advocate)

Good point, that will only fix itself when the cache expires.
Might be worth a mention in the release notes.