Support wildcard method name in @Method/MethodConfig with exact-match precedence (#14927)

[ABin-Huang]

What is the purpose of the change

Close #14927.

The issue asks @Method / MethodConfig to be able to match a group of interface methods with wildcard characters (e.g. @Method(name = "create*", retries = 5, timeout = 6000)), and an explicitly configured method should still win over a wildcard rule for the same method.

This PR implements wildcard method-name matching and exact-match precedence at the config layer, so that annotation, XML, API and properties-based configuration all benefit from the same behavior, while staying fully backward compatible.

Brief changelog / design

• StringUtils
  • Add hasWildcard(String) to detect * / ?.
  • Add isWildcardMatch(pattern, text): * matches any (possibly empty) sequence, ? matches exactly one character, matching is case-sensitive and uses a two-pointer backtracking algorithm instead of regular expressions.
• AbstractInterfaceConfig
  • Add resolveMethodConfigs(Class<?> interfaceClass) which returns an ordered List<Map.Entry<String, MethodConfig>> of resolved method name -> the same MethodConfig instance.
  • Pass 1 expands wildcard configs with putIfAbsent (when several wildcards overlap, the first declared one wins); pass 2 puts exact-named configs so that an exact name always overrides a wildcard for the same method.
  • MethodConfig instances are intentionally not cloned: every resolved name shares the same instance, which keeps non-serializable Spring callbacks such as oninvoke / onreturn / onthrow working.
  • verifyMethodConfig matches method-level configs against the interface methods with the same wildcard rule.
• ServiceConfig / ReferenceConfig
  • Iterate resolveMethodConfigs(...) when appending method parameters and when building async method info, using the entry key as the actual resolved method name. Argument-config type/index resolution in ServiceConfig now uses the resolved method name as well.
• ConfigValidationUtils
  • Add PATTERN_METHOD_NAME_PATTERN ([a-zA-Z*?][0-9a-zA-Z*?]*, allows a bare *) and checkMethodNamePattern; validateMethodConfig uses the looser pattern only when the name contains a wildcard, and keeps the strict identifier rule otherwise.

Default behavior is unchanged: a config without a wildcard resolves exactly as before.

Out of scope (follow-up)

The issue also mentions placing @Method directly on the implementation/interface methods. That is a larger, separate capability (annotation discovery on implementation classes, parent classes and interface methods) and is intentionally left to a follow-up PR; this change focuses on wildcard matching for method-level configs.

Verifying this change

• StringUtilsTest: add testHasWildcard and testIsWildcardMatch (41 tests in total).
• Add MethodConfigWildcardTest with 11 tests covering * / ? matching, exact-over-wildcard precedence, first-declared-wins for overlapping wildcards, provider/consumer parameter expansion, shared-instance semantics, and the no-match case.
• Existing MethodConfigTest keeps passing as regression (21 tests).

All tests pass locally.

Documentation

• A wildcard method name accepts * (any sequence, including empty) and ? (exactly one character); matching is case-sensitive. When both an exact name and a wildcard match the same interface method, the exact configuration takes precedence.

Checklist

• Make sure there is a GitHub_issue field for the change (GitHub issue [Feature] Can @Method annotation provide more possibilities to control which @Method ultimately takes effect with minimal granularity, including on methods of classes using @DubboService annotation, methods of parent classes, and abstract methods of interfaces #14927).
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Check if a new dependency is required: no new dependency.
• Write unit tests to verify the code.
• No new generated files, binary files, or content unrelated to the change.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 86.90476% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 60.92%. Comparing base (dab47b7) to head (9a20578).

Files with missing lines	Patch %	Lines
...g/apache/dubbo/config/AbstractInterfaceConfig.java	79.16%	2 Missing and 3 partials ⚠️
...ache/dubbo/config/utils/ConfigValidationUtils.java	33.33%	3 Missing and 1 partial ⚠️
.../java/org/apache/dubbo/config/ReferenceConfig.java	92.85%	0 Missing and 1 partial ⚠️
...in/java/org/apache/dubbo/config/ServiceConfig.java	85.71%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16457      +/-   ##
============================================
  Coverage     60.91%   60.92%              
- Complexity       15    11762   +11747     
============================================
  Files          1953     1953              
  Lines         89271    89334      +63     
  Branches      13473    13489      +16     
============================================
+ Hits          54383    54428      +45     
- Misses        29309    29323      +14     
- Partials       5579     5583       +4     

Flag	Coverage Δ
integration-tests-java21	32.14% <27.38%> (+<0.01%)	⬆️
integration-tests-java8	32.21% <27.38%> (+<0.01%)	⬆️
samples-tests-java21	32.17% <38.09%> (+<0.01%)	⬆️
samples-tests-java8	29.76% <27.38%> (-0.08%)	⬇️
unit-tests-java11	59.16% <86.90%> (+<0.01%)	⬆️
unit-tests-java17	58.65% <86.90%> (+<0.01%)	⬆️
unit-tests-java21	58.65% <86.90%> (+<0.01%)	⬆️
unit-tests-java25	58.60% <86.90%> (+<0.01%)	⬆️
unit-tests-java8	59.22% <86.90%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 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.