When not wrapping fallback to base64 encoding in case invalid SQS chars are being used

[danielmarbach]

This is a follow-up on:

• Handle sending and receiving metrics messages #2623

Which also addresses:

• Support binary message serialization #2630

Originally, DoNotWrapOutoingMessages was designed to no longer base64 encode and wrap the message with the transport message. The idea was to purely hand over whatever we got to the transport. So in cases of raw dispatches when the message contains characters that are not compliant with the SQS message encoding constraints, the transport would throw.

This has consequences for scenarios like sending metrics when the payload uses raw bytes that may be incompatible with the text restrictions of SQS. By discovering that an encoded payload has characters that are not suitable to be sent and then falling back to base64 encoding, those scenarios are handled.

The transport pump already assumes when it receives non-native messages that the body might be base4 encoded and therefore gracefully falls back to reading those encoded special cases too without any extra code required.

The consequence of the change is that when not wrapping, the payload needs to be inspected for illegal characters which has computational overhead. The current implementation uses the most straightforward approach using a source-gened regex that should be reasonably fast enough. Future optimizations could be done by checking the byte array directly for invalid byte sequences / code points.

[andreasohlund]

The regex adds 12ms when used so that all seems fine