Improve diagnosability for data signal mismatches in StepVerifier with a non-helpful toString() method

[mp911de]

Currently, if an expectation for a data signal fails (StepVerifier.create(…).expectNext(foo)), the error message contains a toString() representation of the expected and the actual data item. This works very well if the class of the emitted item reports sufficient information to diagnose a mismatch (e.g. @Data classes, String, most java.lang types).

Some types (such as Java arrays, ByteBuffer) report information in their toString() method that aren't useful for further diagnosis:

expectation "expectNext(java.nio.HeapByteBuffer[pos=0 lim=7 cap=7])" failed (expected value: java.nio.HeapByteBuffer[pos=0 lim=7 cap=7]; actual value: java.nio.HeapByteBuffer[pos=0 lim=7 cap=7])

It would be helpful to provide more insight to the actual payload, and ideally StepVerifier ships with formatters (ToStringFunction?) for common and well-known Java types that suffer from an informative toString() method.

I'm not sure that it makes a lot of sense to provide a user-configurable API because reactive code comes with a certain complexity and so does test code. We could continue writing test code mono.as(StepVerifier::as).withOptions(…) but I'm a bit torn regarding value vs. complexity.