Structured logging: a failed JSON encode corrupts the next log event written on the same thread

[skdas20]

See gh-51154.

AppendableByteArray.reset() is only reached from toByteArray():

byte[] result = new byte[size];
System.arraycopy(...);
reset();          // only on the success path
return result;

so when to(appendable) in WritableJson.toByteArray(Charset) throws part-way through, the partially written bytes stay in the instance held by the ThreadLocal cache, and get() hands that dirty instance to the next caller on the same thread. In structured logging that means one failed event corrupts the next event into invalid JSON, as reported.

This resets the cached instance when it is handed out rather than when it is drained, so the buffer is clean regardless of how the previous use ended. That also covers the early return in toByteArray():

if (size <= 0) {
    return NO_BYTES;   // returns without reset(), leaving the buffer flipped
}

which the alternative (resetting on the failure path in WritableJson) would not.

Tests added:

• AppendableByteArrayTests.getWhenPreviousUseWasAbandonedReturnsCleanInstance — covers the cache contract directly: append to an instance, never drain it, then assert the next get() returns it clean.
• WritableJsonTests.toByteArrayWhenPreviousWriteFailedDoesNotIncludePartialContent — the reported end-to-end shape: a failed encode followed by an unrelated writer on the same thread.

Both fail on main and pass with the change. org.springframework.boot.json.*, the logging.structured tests, and checkFormatMain/checkFormatTest are all green locally.

I raised the analysis on the issue first and offered either placement — happy to move the reset into WritableJson.toByteArray instead if you'd prefer to keep get() free of side effects, or to close this if you'd rather fix it in-house given it's a regression in recent code.

[snicoll]

@skdas20 thanks for the PR but I decided to go in a different direction. I've reworked the PR, see the polish commit for more details.