feat: add isDuration validator

[os-moussao]

Add isDuration validator for checking duration strings (e.g. "30 Days", "1 week", "10s"). It is designed to match the format of ms, since it's widely used among libraries for duration conversion.

Resolves: #2668

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)
• References provided in PR (where applicable)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (88e0d3d) to head (b1205f5).

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #2669   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          114       115    +1     
  Lines         2590      2602   +12     
  Branches       659       662    +3     
=========================================
+ Hits          2590      2602   +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[WikiRik]

What's the benefit of adding this to the validator library instead of just using that ms library?

[os-moussao]

What's the benefit of adding this to the validator library instead of just using that ms library?

@WikiRik

In my last role, we used to do duration stings as environment variables (especially for JWT, which also uses ms for duration conversion), and we used it for some api routes as well (but rarely).

I figured that stopping at the validation middleware would be better than a try/catch inside controllers/services. Also for the environment it would be better for CI/CD to fail in case of invalid duration rather than accepting any string.

class EnvConfig {
  ...
  @IsString() // this is class-validator, but it uses validator.js
  JWT_EXPIRES_IN: string; // parsed later by ms
  
  @IsString()
  JWT_REFRESH_EXPIRES_IN: string;
  ...
}

One could argue that using numbers directly in body or env-variable would be cleaner, I would say they got a point. However, if providing this validator just adds value without any negative side effects, why not do it.