What is the purpose of the change?

Fixes #16517.

dubbo.protocol.triple.max-message-size (added in #15781) is read by LengthFieldStreamingDecoder, Gzip and Bzip2 through ConfigurationUtils.getEnvConfiguration(...), which only looks at OS environment variables. Setting the limit as a system property, in dubbo.properties or in Spring Boot properties has no effect, so it can neither be lowered nor raised above the 50 MB default that way.

This PR reads the key through ConfigurationUtils.getGlobalConfiguration(...), as the other dubbo.protocol.triple.* keys that are read without a URL already do (rest.json-framework in HttpJsonUtils, rest.disallowed-content-types in CodecUtils, verbose, rest.enabled and rest.openapi.enabled in TripleProtocol). The global configuration covers system properties, environment variables, the config center, Spring Boot properties (copied in by DubboContextPostProcessor) and dubbo.properties.

Behavior change

• Applications that already set dubbo.protocol.triple.max-message-size as a system property, in dubbo.properties or in Spring Boot properties, where it had no effect so far, now get that limit instead of the 50 MB default. A lower limit starts rejecting larger Triple messages with Message size N exceeds limit M (gzip and bzip2 messages that decompress beyond it fail as well); a higher limit lets messages above 50 MB pass the size check. Applications that do not set the key are not affected.
• Environment variables keep working. If the key is set both as a system property and as an environment variable, the system property now wins, following the precedence of the global configuration.

Not covered

A limit set only programmatically through TripleConfig#setMaxMessageSize is still not read: the decoder and the decompressors are created without access to the protocol config (the client stream has no URL). The other keys listed above behave the same way.

Verification

• New tests, all of which fail before the change and pass after it:
  • LengthFieldStreamingDecoderTest#honorsMaxMessageSizeFromSystemProperty
  • LengthFieldStreamingDecoderTest#honorsMaxMessageSizeFromApplicationProperties (sets the key in the application configuration, where Spring Boot properties are copied to)
  • GzipTest#decompressionHonorsConfiguredMaxMessageSize and Bzip2Test#decompressionHonorsConfiguredMaxMessageSize (system property)
• mvn install -pl dubbo-remoting/dubbo-remoting-http12,dubbo-rpc/dubbo-rpc-triple: 25 and 486 tests, 0 failures (2 skipped in each module by @EnabledOnOs(OS.LINUX) / @Disabled); spotless and checkstyle are clean.
• End to end, a Triple provider and consumer in one JVM, limit 1024, request carrying a 4096-character string:

Rejected calls fail with Message size 4130 exceeds limit 1024.

Checklist

• Make sure there is a GitHub_issue field for the change.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Make sure gitHub actions can pass. Why the workflow is failing and how to fix it?