Fix/rule and selector cache not used

[hengyuss]

now rule and selector cache not used, what the pr does is that rule and selector logic don't process default match if rule and selector data exist.
Make sure that:

• You have read the contribution guidelines.
• You submit test cases (unit or integration tests) that back your changes.
• Your local test passed ./mvnw clean install -Dmaven.javadoc.skip=true.

[Aias00]

The core fix looks correct: wrapping defaultMatchSelector/defaultMatchRule in if (Objects.isNull(selectorData)) so a positive L1 cache hit actually short-circuits default matching (previously the cached value was always overwritten). I also checked the invalidation side — CommonPluginDataSubscriber removes both positive and negative match-cache entries on selector/rule update and delete, refreshSelectorDataAll/refreshRuleDataAll clear the whole match cache, and the websocket refreshSelectorDataSelf path is followed by per-item onSelectorSubscribe that invalidates, so I don't see a stale-read regression from making the cache live.

One gap: there's no test covering the new behavior. AbstractShenyuPluginTest runs with the match cache enabled (MatchCacheConfig.enabled defaults to true) but clears MatchDataCache per test and calls execute() once, so the positive cache-hit branch (skip defaultMatchSelector) is never actually exercised — a regression that re-overwrites the cache wouldn't fail any test, and the PR's "test cases" checkbox isn't really met. Could we add a test that calls execute() twice for the same path and asserts matching runs only once, plus a pre-seeded-cache test asserting the cached SelectorData/RuleData is the one passed to doExecute? A test asserting re-match after onSelectorSubscribe invalidation would also lock in that contract.

Minor: the branch is behind master and needs a rebase before merge.

[Aias00]

Correct fix — the cache hit path was being clobbered. Previously selectorData = defaultMatchSelector(...) ran unconditionally, so even when the match-data cache returned a non-null selectorData, it was immediately overwritten by a fresh default-match pass (and same for ruleData). The double null-gate (if (isNull) { defaultMatch; if (isNull) handleIfNull; }) means the cache result is now respected and the expensive match only runs on a cache miss. Behavior for the null/no-cache path is unchanged.

Minor: the diff also carries a lot of trailing-whitespace / param-alignment churn. Harmless, just makes the substantive ~8-line change harder to spot in review.