PayloadS3Pointer inefficiently uses Jackson's ObjectMapper

[Logic-32]

Ref:

• PayloadS3Pointer
• JsonDataConverter
• https://github.com/FasterXML/jackson-docs/wiki/Presentation:-Jackson-Performance#basics-things-you-should-do-anyway

Reuse heavy-weight objects: ObjectMapper (data-binding) and JsonFactory (streaming API)
To a lesser degree, you may also want to reuse ObjectReader and ObjectWriter instances -- this is just some icing on the cake, but they are fully thread-safe and reusable

Short version:

1. PayloadS3Pointer instantiates a new JsonDataConverter for every toJson() invocation.
2. JsonDataConverter instantiates a new ObjectMapper for every invocation.

When used via a S3BackedPayloadStore in the SQS Extended Client and sending a ton of SQS messages, this can add up to quite the performance hit.

If you flipped this on its head and

1. Had the PayloadStore contain an ObjectMapper
2. Got rid of the toJson() method
3. Serialized the PayloadS3Pointer directly in the PayloadStore
   • Probably via an abstraction containing the ObjectMapper so you could encapsulate the Exception handling nicely
   • See also: https://testing.googleblog.com/2020/12/testing-on-toilet-separation-of.html

Then you could see some performance benefit by having one ObjectMapper per-PayloadStore. But, making a static, hidden, shared ObjectMapper throughout the entire library would see the biggest benefits. Again, probably contained in a Singleton wrapper class that is used and/or injected everywhere.