Protect GeoJSONFeature from ProGuard alterations

[grzesiek2010]

Closes #5812

Why is this the best possible solution? Were any other approaches considered?

We use com.fasterxml.jackson in javarosa to map geojson files into java classes. One of those classes is GeoJSONFeature class with its private Map<String, String> properties field. So properties are pairs where both keys and values should be strings. When it comes to keys it's not a problem because in geojson they are always just strings but values could be integers for example:
"properties": { "_uid_": 1,...
com.fasterxml.jackson takes care of that and automatically converts those values into strings because that's what we expect private Map<String, String> properties. However, if minification is enabled ProGuard messes up with that class disabling that conversion.
The fix is to let ProGuard know that this class should be intact.

Another solution would be to change private Map<String, String> properties to private Map<String, Object> properties and always programmatically convert those object values to strings. However, if com.fasterxml.jackson does that for us (if ProGuard does not break it) we should still take advantage of it I guess.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Testing the form shared on the forum (see the issue) should be enough. I can't be sure that we don't have other issues like this one caused by proguard but the fix itself is safe so we can focus on testing the described scenario.

Do we need any specific form for testing your changes? If so, please attach one.

No.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew checkAll and confirmed all checks still pass OR confirm CircleCI build passes and run ./gradlew connectedDebugAndroidTest locally.
• added a comment above any new strings describing it for translators
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[seadowg]

Nice fix!

In general, it makes sense to keep classes for anything being serialised as it's really easy for ProGuard to mess up any meta programming magic. Maybe we should also keep GeojsonGeometry as well to defend against a similar problem in the future?

[grzesiek2010]

In general, it makes sense to keep classes for anything being serialised as it's really easy for ProGuard to mess up any meta programming magic.

I was thinking about it and for example, introducing an annotation that we could later use in proguard to exclude classes that should not be changed (without listing all of them and just using the annotation) but I think it would be easy to forget either way so it doesn't make sense.

Maybe we should also keep GeojsonGeometry as well to defend against a similar problem in the future?

I'm not sure but we can do that.