[BUG] General setRules command decodes rule data twice #3665

Issue Description

Type: bug report

Describe what happened

The general setRules handler URL-decodes data after the HTTP transport has already decoded it. With an ordinary once-encoded request, a resource containing + is stored with a space, a literal %2B becomes +, and a lone % can make an otherwise valid rule fail to load. The modified value also reaches a registered writable data source.

This affects ModifyRulesCommandHandler in sentinel-transport-common. It is separate from the parameter-flow handler addressed in #3628.

Describe what you expected to happen

The resource in the rule manager and writable data source should match the JSON submitted by the client. Transport decoding should happen once.

How to reproduce it (as minimally and precisely as possible)

1. Start an application with Sentinel's simple HTTP or Netty HTTP command transport.
2. Submit a rule, using its command port:

curl --data-urlencode 'type=flow' \
  --data-urlencode 'data=[{"resource":"api+v1","limitApp":"default","grade":1,"count":10,"strategy":0,"controlBehavior":0}]' \
  http://localhost:8719/setRules
curl 'http://localhost:8719/getRules?type=flow'

3. The returned resource is api v1, rather than api+v1. Replacing the resource with api%2Bv1 or api50%off exposes the other cases. A once-encoded GET query has the same problem.

Tell us your environment

Current 1.8 branch, commit a3f40ba8e900c8489bd520274739f17235a7721c (1.8.11-SNAPSHOT); macOS arm64, Microsoft OpenJDK 17.0.18.

Anything else we need to know?

I have a fix in progress for the general handler. Regression tests exercise the handler directly, real simple-HTTP socket requests, and the Netty HTTP pipeline, checking both loaded rules and writable-data-source values. Against the current branch, 19 of 33 cases fail; the ordinary ASCII, space and Unicode controls pass. With the redundant decode removed, all 33 pass.