Improve signalling for JSON payloads

[skjolber]

For the combination JSON logging and JSON request/response payloads, make it so that processing details relevant for logging are propagated, so that duplicate work can be avoided.

Detailed Description

Currently JSON payloads are append as raw content within JSON request/response-logging statements. This means that payloads with invalid JSON syntax can / will result in log statements with invalid JSON syntax too. So log accumulation tools will not be able to parse the statement as JSON, and might discard the message, or fall back to handle the log statement as pure text.

However existing body-filters and/or databinding performed in the service may be leveraged to guarantee that the payloads are in fact valid JSON. The logging subsystem can safely append the raw data if it knows that the body

• does not contain newlines
• is well-formed JSON

If those parameters are unknown, the logging subsystem can attempt to validate the JSON syntax itself and remove newlines. Then continuing to append the payload as raw content, or escaping the payload as JSON text if invalid JSON syntax.

Context

A JSON message might be parsed up to three times,

• in a body filter
• in the service databinding
• when writing the log

The last might be avoided.

Possible Implementation

Add a wrapper for body. This would be a breaking change.

[github-actions]

In order to prioritize the support for Logbook, we would like to check whether the old issues are still relevant.
This issue has not been updated for over a year.

• Please check if it is still relevant in latest version of the Logbook.
• If so, please add a descriptive comment to keep the issue open.
• Otherwise, the issue will automatically be closed after a week.

[skjolber]

Still relevant, might also be interesting to add some metadata indicating if/how a payload was filtered, i.e. "4500 bytes was filtered" etc.

See also #1330