Pick Serializer using properties

Hello Optimizely team:

We have encountered issues while working with Optimizely. The SDK allows to use two different serialisers in an uncontrolled way, by letting you pick one using optimizely.properties (in out experience, it is used while retrieving your organisation experiments file, I don't know for what else it is used):
DefaultConfigParser

But in this one where the events are raised, since it is an if/else structure, you have no control over it, and in our case it does not work because we use a Jackson version previous to 2.7, throwing an exception while trying to create it with the SNAKE_CASE property (one exception that we will avoid if GSON could be chosen):
DefaultJsonSerializer

I feel like this is an inconsistency and since it is already implemented for one scenario, it should be paired for the event ones.
We also know that this is our fault for not using that Jackson version, but it is done in a service where that specific library is almost impossible to update... We have discarded the idea of integrating Optimizely in that specific service, but we thought that it was important to let you know this weird behaviour where you can have GSON (or any other one) + Jackson (or any other one) working simultaneously.

Thanks for reading, let us know if you change anything about this!

Start by comparing core-api/src/main/java/com/optimizely/ab/config/parser/DefaultConfigParser.java with core-api/src/main/java/com/optimizely/ab/event/internal/serializer/DefaultJsonSerializer.java, focusing on how optimizely.properties selects a serializer. Confirm that event serialization can honor the same selection, and verify that both GSON and Jackson configurations work consistently.