refactor: replace fastjson1 with fastjson2 on the 0.3.2 line

[RongtongJin]

Summary

• replace fastjson1 usage on release-0.3.2-next with fastjson2 2.0.64
• preserve the legacy Base64 JSON representation of byte[] in RPC payloads and snapshot metadata
• upgrade rocketmq-remoting from 4.9.4 to 5.5.0 and exclude its transitive fastjson1 dependency
• handle the InvokeCallback.operationFail path used by newer RocketMQ Remoting versions
• cover JDK 8 cold-start serialization through the real RocketMQ Remoting codec

Compatibility details

A direct import replacement changes fastjson2's default byte[] output from a Base64 string to a numeric array. DLedgerJsonUtils therefore writes with WriteByteArrayAsBase64 and reads with Base64StringAsByteArray. Tests include a literal fastjson1 Base64 fixture plus append, batch append, push, snapshot, and real network round trips.

RocketMQ Remoting 4.9.4 itself uses fastjson1 for command headers, so removing fastjson1 also requires a Remoting upgrade. This uses 5.5.0, matching current DLedger master and RocketMQ. Its asynchronous connection-failure path calls operationFail; every DLedger callback now completes its future from that path.

Fastjson2 2.0.63 has a JDK 8 initialization-order regression (fastjson2#7691) fixed in 2.0.64 (fastjson2#7718). This PR now uses the upstream fix instead of an application-level MethodHandles prewarm. A fresh JDK 8 subprocess directly round-trips a real ConsumerConnection through RemotingSerializable, which reproduces the Invalid caller failure on 2.0.63 and passes on 2.0.64. The corresponding RocketMQ version-alignment change is apache/rocketmq#10928.

Known API caveat: RocketMQ Remoting 5.5.0 adds ChannelEventListener.onChannelActive. Downstream custom listener implementations built against the old interface need to implement that method when rebuilding. Mixed 4.9.4/5.5.0 rolling-upgrade interoperability has not yet been exercised; the DLedger body-format compatibility is covered here, while Remoting header interoperability relies on RocketMQ Remoting's protocol compatibility.

Verification

• Amazon Corretto JDK 8 full reactor: dledger 57 tests and dledger-proxy 11 tests, all passing
• fresh-process JDK 8 Remoting cold-start test passes without DLedger prewarming
• real Netty append/get round trip preserves binary bodies
• Base64 codec and legacy golden-fixture tests pass
• repository Checkstyle and full reactor package pass
• resolved dependency tree contains rocketmq-remoting:5.5.0, rocketmq-common:5.5.0, and fastjson2:2.0.64, with no fastjson1 artifact
• shaded DLedger.jar contains fastjson2 and no com/alibaba/fastjson/ classes

This targets the 0.3.2 maintenance/development line, currently versioned 0.3.3-SNAPSHOT, and includes the documented Remoting public-interface and mixed-version caveats.

[3424672656]

lgtm