fix: allow regex resource names with all control behaviors

[EvanYao826]

Issue Description

Fixes #3544

Previously, regex resource names were only allowed with CONTROL_BEHAVIOR_DEFAULT (fast failure). This restriction prevented users from using warm-up or queue behaviors with regex-matched resources.

Changes

In FlowRuleUtil.checkRegexField(), removed the control behavior restriction for regex rules. Now regex resource names can be used with any control behavior (DEFAULT, WARM_UP, RATE_LIMITER, WARM_UP_RATE_LIMITER), as long as the rule is not in cluster mode.

Before:

if (rule.isRegex()) {
    return !rule.isClusterMode() && rule.getControlBehavior() == RuleConstant.CONTROL_BEHAVIOR_DEFAULT;
}

After:

if (rule.isRegex()) {
    return !rule.isClusterMode();
}

Testing

Verified that flow rules with regex resource names can now be loaded with all control behaviors.

[oss-sentinel-ai]

Summary

This PR relaxes checkRegexField so regex flow rules can be combined with all control behaviors (previously restricted to CONTROL_BEHAVIOR_DEFAULT). The change is safe for DefaultController (stateless) and ThrottlingController (its shared latestPassedTime naturally acts as a global rate limiter), but there is a semantic mismatch with the warm-up behaviors — see inline comments.

Findings

• [Warning] FlowRuleUtil.java:249 — Warm-up controllers keep per-instance token-bucket state shared across all regex-matched resources while syncToken() reads per-resource QPS; warm-up behavior becomes unpredictable when matched resources have different traffic (details inline).
• [Info] FlowRuleUtil.java:249 — The identical restriction still exists in ParamFlowRuleUtil.checkRegexField() for parameter flow rules (details inline).

Suggestions

• Consider allowing only CONTROL_BEHAVIOR_RATE_LIMITER (plus default) with regex rules, or explicitly document that warm-up behaviors operate on shared state across all matched resources.
• Add an integration test covering regex + rate-limiter behavior (existing tests only cover regex + default).

---

Automated review by github-manager-bot

[oss-sentinel-ai]

WarmUpController and WarmUpRateLimiterController maintain per-instance token bucket state (storedTokens, lastFilledTime) that is shared across all resources matching the regex pattern, but syncToken() reads passQps() from the individual per-resource Node. When a regex rule matches resources with different traffic levels, the warm-up behavior becomes unpredictable: sync triggered by a low-QPS resource keeps the bucket full (perpetual warm-up state), while a high-QPS resource drains it quickly. ThrottlingController (rate limiter) works correctly since its shared latestPassedTime naturally implements a global rate limit. Consider either: (1) restricting this change to only allow CONTROL_BEHAVIOR_RATE_LIMITER with regex, or (2) documenting that warm-up behaviors with regex have shared-state semantics across all matched resources.

[oss-sentinel-ai]

The identical regex + control-behavior restriction exists in ParamFlowRuleUtil.checkRegexField() (sentinel-extension/sentinel-parameter-flow-control). If the restriction is being relaxed here for flow rules, consider whether the same change should apply to parameter flow rules for consistency.