Serialize the LogEvent message delegate through the filtered wrapper

[ppkarwasz]

Important

This PR is part of the deserialization hardening work tracked in #4168. The Logging Services PMC does not use nor recommend Java serialization/deserialization, and our security FAQ has long documented this position. This work is submitted solely to reduce the false-positive "vulnerability" reports that keep being filed regardless of that FAQ. Its utility for end users is close to zero.

Since 2.8.2, Log4jLogEvent.LogEventProxy transported its Message delegate inside a java.rmi.MarshalledObject. MarshalledObject.get() deserializes its embedded bytes on a private, unfiltered ObjectInputStream, so the nested message bypassed both FilteredObjectInputStream and the JEP 290 filter.

The message is now written with the same SerializationUtil.writeWrappedObject/readWrappedObject mechanism already used by ObjectMessage, which re-applies the deserialization filter to the nested stream, and java.rmi.MarshalledObject is removed from the allowlist. A message that is rejected or unreadable on the receiving side degrades to a SimpleMessage built from the formatted message string, as before.

Compatibility: this changes the serialized form of LogEventProxy.

• Log events serialized by Log4j 2.8.2–2.25.x are rejected by readers with this change, since MarshalledObject no longer passes the filter.
• Events serialized with this change remain readable by older versions, with the message downgraded to a SimpleMessage.
• Previously, a message that threw during serialization was silently replaced by its formatted string on the writing side; matching ObjectMessage semantics, such a failure now propagates to the caller as an IOException.

The serialized-event fixture in Log4jLogEventTest predated nanoOfMillisecond and the trace-context fields and has been regenerated; the stale serializedEvent.dat test resource was unused (SerializedLayoutTest always rewrites it before reading) and is removed.

Stacked on #4270.

[ramanathan1504]

writeWrappedObject serializes into a ByteArrayOutputStream and touches s only in its last statement. So a failed attempt leaves s untouched and a fallback write is still well formed.

try {
    SerializationUtil.writeWrappedObject(message, s);
} catch (final Exception ex) {
    SerializationUtil.writeWrappedObject(new SimpleMessage(messageString), s);
}

messageString is set two lines above and message() already prefers message over it, so the reader needs no change.

[ramanathan1504]

The MarshalledObject removal looks complete. Dropping serializedEvent.dat is fine too, testDeserialization calls testSerialization() first.

One problem. A Message with a non-serializable field used to be caught by marshall and replaced by messageString. Now it throws NotSerializableException out of the
whole event. SerializedLayout.toByteArray catches that and still returns the partly written buffer. Fix inline.

[ramanathan1504]

Old streams also stop being readable. defaultReadObject still resolves java.rmi.MarshalledObject from the stream's own field descriptor before dropping the value, and
that class is off the allowlist now. So events written by 2.8.2 to 2.25.x are rejected. That is a wire break on 2.x, worth a PMC note rather than riding in with the
hardening.

And nothing tests the new behaviour. Neither the filtered nested read nor the fallback to SimpleMessage is covered. The regenerated base64 fixture passes either way, even
with an unfiltered nested stream.