Extended SQL message field type support

[therealryan]

All message types offer two serialisation mechanisms:

• assertable() - creates a human-readable string that can be usefully diffed in test assertions
• content() - creates the bytes of the message as you'd see on the wire

The peer( byte[] ) method is the counterpart to content() - it method parses message data from a byte array.

The byte[] representation of messages is pretty crucial lowest-common denominator - you might be dealing with message types where you really, really care about the exact byte values. For most message types it's less important (e.g.: json key/value order isn't significant).

For the SQL messages we're not trying to implement any particular SQL implementation wire protocol, so instead we just use jackson to splat the message data into json.
The problem is that SQL messages are more heavily typed than json is, so the encode/decode roundtrip will, e.g., turn a byte[] into a base64 string, which is really unhelpful if you have a message dependency that expects to consume a byte[].

#157 fixed that specific example, but now I've been writing tests for a system that involves java.sql.Timestamp, so we're back to cover all of the jdbc types. The change is just to add more typed fields in TypedKVP so that value type is preserved in the round-trip through json.

In the process we've had to deal with a chromedriver bug that's just popped up, and followed the recommendation linked from that bug report to provoke the latest headless mode.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
4 Code Smells

100.0% Coverage
0.0% Duplication