fix: update UUID validation to support versions 1-8, nil, max, and all

[PleBea]

Description

Updated the IsUUID tests to align with the updated JSDoc, which specifies support for all UUID versions (1-8, nil, max, all).

Previously, the tests primarily covered versions 3, 4, and 5. I have added test cases to verify that the IsUUID decorator correctly validates all UUID specifications supported by the underlying validator.js library, including versions 1, 2, 6, 7, 8, nil, and max.

Checklist

• the pull request title describes what this PR does (not a vague title like Update index.md)
• the pull request targets the default branch of the repository (develop)
• the code follows the established code style of the repository
  • npm run prettier:check passes
  • npm run lint:check passes
• tests are added for the changes I made (if any source code was modified)
• documentation added or updated
• I have run the project locally and verified that there are no errors

Fixes

fixes #2581
fixed #2648

[WikiRik]

Maybe #2648 can also be fixed with this PR? Since it's the same validator that requires an update

[PleBea]

Maybe #2648 can also be fixed with this PR? Since it's the same validator that requires an update

Yes, that's correct. This PR now specifically addresses issue #2648 as well.

I've made a small adjustment/tweak to the relevant code (the validator) to ensure it correctly fixes #2648. Once this PR is merged, we can close that issue.

[Setitch]

Question: In which situation i would set constant validation to nil uuid value? If i do that - its better to omit the field at all and put nil value directly further in the code instead.

[PleBea]

Good question! Here are some real-world use cases for nil UUID validation:

1. Databases without nullable UUID columns: Some databases (e.g., certain configurations of PostgreSQL, or when using ORMs with non-nullable UUID primary keys) use nil UUID as a sentinel value to represent "not set" instead of NULL.

2. UUID-based foreign key placeholders: When a foreign key relationship is optional but the column must be a valid UUID, nil UUID serves as the "no reference" value.

3. Distributed systems / Message queues: Some systems use nil UUID as a default/placeholder value in message schemas where the field is required but not yet populated.

4. API contract validation: When receiving data from external services that use nil UUID in their spec (e.g., some Microsoft APIs use nil GUID as a special value).

5. Completeness with validator.js: Since the underlying validator.js library already supports nil version, exposing it in class-validator maintains feature parity and gives users the full flexibility the library offers.

The key difference from omitting the field: omitting means "field doesn't exist" while nil UUID means "field exists with an explicit 'empty' value" - these have different semantic meanings in many systems.

[Setitch]

Valid point, though why allowing only NIL value to be used? I mean, why not each? I think it would be better to have something like: V7 + NIL + MAX, V1 + NIL, V4 + MAX, instead of just MAX or just NIL.

[PleBea]

Good point! I'll add support for version arrays so you can validate against combinations like ['7', 'nil', 'max'] or ['1', 'nil']. The validation will pass if the UUID matches any of the specified versions.

[Setitch]

Question: In which situation i would set constant validation to max uuid value? If i do that - its better to omit the field at all and put max value directly further in the code instead.

[PleBea]

You're right that max UUID has fewer practical use cases compared to nil. Here's my reasoning for including it:

1. RFC 9562 compliance: Both nil and max UUIDs are defined in RFC 9562 as special UUID values. Including both maintains compliance with the specification.

2. Feature parity with validator.js: The underlying validator.js library supports max as a version option. This PR aims to expose all the UUID validation capabilities that validator.js provides, rather than cherry-picking which ones to support.

3. Range queries: In some database scenarios, max UUID can be used as an upper bound for range queries on UUID columns (similar to how nil serves as lower bound).

4. Consistency: If we support nil (all zeros), it makes sense to also support max (all f's) for symmetry.

That said, I agree max is rarely used in practice. If you prefer, I can remove max (and potentially nil) from this PR and focus only on loose mode, which has clearer practical value. Let me know your preference!