Remove or fix IUnknownPropertiesConsumer implementation

[marandaneto]

Relates to #1420 but can be done standalone.
The IUnknownPropertiesConsumer implementation today is different than expected, we can either fix it or remove it as the 'unknown' map that this implementation generates is usually dropped during ingestion.

Not all protocol classes accept non-mapped fields, but we implement IUnknownPropertiesConsumer for every protocol class, this should also be addressed.

It's not a high priority issue though because it only affects hybrid SDKs or when one downgrade the SDK and has a cached envelope that has now a field that is unknown.

[bruno-garcia]

Is there a way to do this with the current reflection-based serialization approach? We've been reconsidering vendoring the handful Gson classes needed to do 'manual' serialization/deserialization and drop the Gson dependency. While doing so we could address this issue by keeping unknown json keys into a Map<> and serializing back into the JSON when a round-trip serialization happens.

It will hopefully address #1420 too since we wouldn't depend on Gson.

Another added benefit is to avoid the Gson version conflict that comes up from time to time:

ERROR: Request failed, API returned 400
ERROR: {"detail":"empty envelope"}.

[marandaneto]

I believe it's possible to fix with the current implementation, yes, it'd require adapters for every single protocol class probably.
I'd focus on #1420 and fix this issue while doing it, which is win-win, no reflection, no gson, and doing it by hand is easy to survive unknown fields during round trip.

[marandaneto]

closed by #1554