CSRF detection should identify empty or problematic CSRF tokens

Is your feature request related to a problem? Please describe.
If a web application delivers an empty or inappropriate value for a CSRF token and accepts this token, this is not flagged because the token exists.This leads ZAP to flag the request as including a CSRF token (correctly, as it does), but it is clearly not a useful CSRF token.

Describe the solution you'd like
Alerting on CSRF tokens below a given length, that length could be configurable in options (per context?) allowing it to be set to a value to avoid false positives if a site uses unduly short CSRF token. But long enough to catch common silly values "","null", "false". Also consider a CSRF token.

Describe alternatives you've considered
CSRF tokens are of decreasing value due to changes in browsers, so possibly do nothing ;) Or leave users to write their own rules to flag special cases with regular expressions, or an extensions that does same. Also wonder if "", "null", "false", are special cases that could simply cause the CSRF token to be ignored requiring no interface changes for the user, or simply add a new alert for these cases again with no interface change.

Additional context

Would you like to help implementing this feature?
Love to, although I'm familiar with many aspects of modern Java development my last professional Java IDE was Borland JBuilder 1 (circa 1997) so that may require a fair bit of hand holding. The couple of lines in AntiCsrfDetectScanner.java that look like they do the actual work are voodoo to me, but I suspect that is more to do with how the app scans HTTP responses than my Java knowledge.

Start with AntiCsrfDetectScanner.java, the file identified as containing the relevant detection logic. Clarify whether completion means a configurable minimum length, special-case handling for values such as "", "null", and "false", or a new alert, then trace the scanner behavior needed to implement and verify the agreed choice.