[PERFORMANCE] Cache and reuse Object mappers for writing JMAP responses

[chibenwa]

Clients use a close ensemble of properties combination in JMAP responses.
This enable reuse of jackson assemblies and achieve significant speedup
of JMAP responses serialisation.

Before

~20% of James applicative CPU time is spent doing JMAP response serialization. This is because each request needs a dedicated property filter, which is implemented by always initializing a new ObjectMapper, which takes time and is sub-optimal as it is not warm.

Here are the associated gatling run:

After

By caching common serialization patterns we decreased 6 time CPU utilization for JMAP Draft response serialization.

Here are the associated gatling run:

[chibenwa]

13:01:20.832 [ERROR] o.a.j.j.d.m.SetMessagesCreationProcessor - An error occurred when deleting a message
java.lang.IllegalStateException: block()/blockFirst()/blockLast() are blocking, which is not supported in thread reactor-http-epoll-6
	at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:83)
	at reactor.core.publisher.Mono.block(Mono.java:1703)
	at org.apache.james.mailbox.inmemory.mail.InMemoryMessageIdMapper.find(InMemoryMessageIdMapper.java:71)
	at org.apache.james.mailbox.inmemory.mail.InMemoryMessageIdMapper.delete(InMemoryMessageIdMapper.java:127)
	at com.google.common.collect.RegularImmutableMap.forEach(RegularImmutableMap.java:186)
	at org.apache.james.mailbox.store.mail.MessageIdMapper.delete(MessageIdMapper.java:76)
	at org.apache.james.mailbox.store.mail.MessageIdMapper.lambda$deleteReactive$2(MessageIdMapper.java:80)

Looks weird...