[ISSUE #7979] update stale matching-cache documentation after trie removal - #8117

Documentation-only cleanup, and I checked the new wording against the code rather than taking it on trust. Everything the PR asserts is accurate; two small follow-ups below, neither blocking.

Verified

• manyMatchSelector → matchSelector. The old name does not exist in AbstractShenyuPlugin; matchSelector (private, line 247) does. The stale cross-reference was the one genuinely misleading part of that Javadoc, since it pointed at a method a reader would not find.

• "prefers the matching selector with the most conditions before comparing sort" matches the implementation exactly:

  int specificity = MatchModeEnum.match(selector.getMatchMode(), MatchModeEnum.AND)
          ? CollectionUtils.size(selector.getConditionList()) : 0;
  if (Objects.isNull(best) || specificity > bestSpecificity
          || specificity == bestSpecificity && selector.getSort() < best.getSort()) {

  Condition count first, sort only as the tiebreaker — which is also the property HttpRouteParser relies on when it pads selectors to a common condition floor.

• execute comment now describes obtainRuleDataCacheIfEnabled(path) followed by default matching on a miss, which is what the method body does.

• The dangling ## selector L2 cache, use trie as L2 cache in shenyu-integrated-test-k8s-ingress-websocket/application.yml was the only one of the three k8s-ingress configs still carrying it; removing it is correct and behaviour-neutral (it was a comment with no YAML value under it).

• LocalPluginController and CommonPluginDataSubscriber comment rewrites are accurate.

• RELEASE-NOTES.md still mentions the trie and is correctly left alone — those are historical notes, not current-state documentation.

Two follow-ups

1. Constants.TRIE_CHILDREN_SIZE, TRIE_PATH_VARIABLES_SIZE, TRIE_PATH_CACHE_SIZE are dead.

All three are still declared in shenyu-common/.../constant/Constants.java (lines 851–864) and referenced nowhere else in the repository. If the trie was removed in #6303, these should have gone with it. Removing them here keeps the cleanup in one place and is the kind of thing that only gets harder to spot later — a reader who finds TRIE_PATH_CACHE_SIZE will reasonably assume a trie still exists somewhere.

2. The HttpRouteParser padding comment gives the right conclusion for the wrong reason.

// Only the selector is padded: rules compete only within their own selector, so padding them would add nothing.

matchRule uses exactly the same condition-count-first-then-sort comparison as matchSelector:

int specificity = MatchModeEnum.match(rule.getMatchMode(), MatchModeEnum.AND)
        ? CollectionUtils.size(rule.getConditionDataList()) : 0;

so rules do compete on condition count inside their selector, and if a selector ever carried several rules, padding them would matter. The actual reason padding is unnecessary is that addSelectorRule emits exactly one rule per selector:

routeConfigList.add(new IngressConfiguration(selectorData, List.of(ruleData), null));

Suggest stating that directly — "each generated selector carries a single rule, so rule padding has nothing to order" — otherwise the next reader may conclude rule padding is skippable for a reason the code does not support, and re-derive the wrong invariant if the one-rule-per-selector structure ever changes.

CI

At the time of writing pr_build and the it/e2e matrix are still queued; check-license-header, CodeQL and changes have passed. Nothing in this diff can affect compilation, so I am not waiting on it — but please make sure the full run goes green before merge.

Approving.