fix: default the Jackson max-decompressed-size to unlimited

[pjfanning]

Motivation

#3491 bounded Jackson payload decompression with
pekko.serialization.jackson.compression.max-decompressed-size, defaulting to 256 MiB. A
bounded default could reject a payload an existing system legitimately exchanges, so a
patch release carrying it could break running systems on upgrade, and there is no default
that is provably above every deployment's largest payload. The bound should be opt-in,
matching the change made to pekko.serialization.max-decompressed-size in #3502.

Modification

Default the setting to unlimited, meaning no limit and matching the behaviour of
releases before #3491, in both serialization-jackson and serialization-jackson3. A
negative number such as -1 also means unlimited — the convention of the neighbouring
read.max-document-length and read.max-token-count settings — per review, so both
spellings are accepted. Operators who want the protection set a size such as 256 MiB,
larger than anything their system legitimately sends.

An unlimited maximum skips the gzip size check and the LZ4 declared-size check. A negative
declared LZ4 size is still rejected — it is malformed regardless of the limit — and now
with a message saying that, rather than one claiming it exceeds the maximum.

Config's getBytes refuses both spellings, so the setting is read as a string first and
as a memory size only when it is neither unlimited nor a negative number.

Result

Jackson payload decompression is unbounded by default; configuring a size bounds it. A
configured limit behaves exactly as before.

Tests

Three new tests per module (so each runs under both the JSON and CBOR serializers):

• apply no gzip decompression limit when max-decompressed-size is -1
• apply no lz4 decompression limit when max-decompressed-size is -1
• apply no decompression limit when max-decompressed-size is unlimited

The -1 tests were checked to discriminate by reverting the production change and
re-running: each then fails with ConfigException$BadValue: Attempt to construct memory size with negative number: -1, which is also what an operator configuring -1 on the
current code would get at serializer construction; unlimited fails the same way as a
BadValue on the keyword.

• sbt "serialization-jackson/testOnly org.apache.pekko.serialization.jackson.*" — passed
• sbt "serialization-jackson3/testOnly org.apache.pekko.serialization.jackson3.*" — passed
• sbt "serialization-jackson/scalafmtCheckAll" "serialization-jackson3/scalafmtCheckAll" — clean
• sbt "serialization-jackson/mimaReportBinaryIssues" — no issues (serialization-jackson3
  disables MimaPlugin)

References

Refs #3491, Refs #3502

[pjfanning]

I want to backport #3491 with this PR's modification as part of the 1.7.1 release. The limit becomes opt-in as a result.

[nvollmar]

Pekko overall is a bit inconsistent in this, some settings use -1 for unlimited, some settings use

max-received-message-size = unlimited

In general I find such keys more clear than using magic numbers like -1 or 0 that change the meaning of the setting.

Maybe something we can address in 2.0

[pjfanning]

Good point. Changed so that both spellings work: the default is now written as unlimited, and a negative number such as -1 is also accepted (matching the neighbouring read.max-document-length / read.max-token-count convention). The same dual handling is applied to pekko.serialization.max-decompressed-size in #3502 so the two sibling settings stay consistent.