Change HAS condition type to always use String in @whereConditions

[DrPowerSlam]

#2723

• Added or updated tests
• Documented user facing changes
• Updated CHANGELOG.md

Changes

Changes the condition type of HAS arguments in @whereConditions to always use String type, so the column type isn't inherited from the parent node.

Breaking changes

Technically this is a breaking change, since users that currently use the unupdated code will go from an Enum type to a String type.
However, I would argue that it's almost impossible to correctly use the current functionality, since you need a perfect overlap between columns in a node and all its relations to make it work.

[spawnia]

Released with https://github.com/nuwave/lighthouse/releases/tag/v6.64.2, thank you

[oortasertecfarma]

This ended up being a breaking change for my project, despite being released as a patch.
Might be worth at least a minor bump to better match semver expectations.

[spawnia]

@oortasertecfarma How did this break your project? I was inclined to agree with @DrPowerSlam assessment:

it's almost impossible to correctly use the current functionality, since you need a perfect overlap between columns in a node and all its relation

[Saarnaki]

@oortasertecfarma How did this break your project? I was inclined to agree with @DrPowerSlam assessment:

it's almost impossible to correctly use the current functionality, since you need a perfect overlap between columns in a node and all its relation

Can't speak for @oortasertecfarma , but this was a breaking change for me as well. This increased the cached schema file size from 17mb to 21mb, which caused memory exhaustion errors in ASTCache.php fromCacheOrBuild method, line 64, while reading the cache file.

[oortasertecfarma]

After looking into it, the issue that occurred in my project after upgrading was caused by a custom override of manipulateArgDefinition in WhereConditionsBaseDirective, which already allowed the use of String in HAS conditions and covered a slightly broader use case.
Once I aligned the override with the new explicit behavior introduced in this PR, all tests are passing again.

Regarding the schema size mentioned above, I also checked it on my side.
In my case, the increase was relatively small, going from ~13.94 MB to ~13.96 MB in the cached schema.