[Code health] Introduce protos as structure for checking data in Firestore at compile-time

[gino-m]

See also google/ground-platform#1277

@os-micmec FYI tracking bug also here

Proposed micro-design (read):

1. Use DocumentSnapshot.getData() to fetch data as a Map<String!, Any!>
2. Tweak data in Map when needed. We should try to minimize special logic in this layer.
3. Recursively wrap Map in Gson JsonElement and related classes.
4. Use Gson to populate classes generated with json-kotlin-schema-codegen

We would do the reverse for writing:

1. Convert object to JsonElement using Gson
2. Convert JsonElement to Map
3. Tweak Map as needed.
4. Pass Map to update methods in Firestore libs.

We can preserve our current representation of nested arrays, using indexed maps instead.

Alternatives considered:

• kpropmap libraries requires conversion to its own PropertyMap interface. It's also not clear how we'd implement polymorphism or custom (de)serializers.
• kotlinx.serialization Properties requires @Serialization annotations on data classes (issue). Our data classes are generated, so we can't do that. Also not correct - you can set custom annotations
• Gson and kotlinx.serialization Json require conversion to/from JSON strings, which can be slow. <-- not true - we can also recursively wrap our object graph to JsonObject and JsonElement as per this example
• DocumentSnapshot.toObject doesn't handle polymorphism, and doesn't offer much flexibility in customizing mappings.

@sufyanAbbasi FYI

Comments which follow are from early research and are out of date.

[gino-m]

Perhaps something like JSON Schema could also work?

Code gen:

• https://github.com/pwall567/json-kotlin-schema-codegen
• https://github.com/jimblackler/jsonschematypes/tree/master/codegen

[gino-m]

There's currently no easy way to do this. We could use something like quicktype to generate model code from JSON Schema, but that would require data to be converted to JSON and then parse (wasteful), and it's not as customizable so classes like GeoPoint won't be accessible. Firestore doesn't support this by design (filed this FR), so we'd need to roll our own. Dart isn't supported on Cloud Functions (see FR), so even if we can share model and logic between Angular and Android, we'd still need another impl there.

[gino-m]

A good place to start might be https://sianloong90.medium.com/step-by-step-build-a-kotlin-multiplatform-library-sdk-part-1-e973bdbfa55d

[gino-m]

A few more notes:

• Koltin collections aren't supported in JS (see Kotlin types in JavaScript).
• Kotlin immutable collections looked promising for cross-platform immutable collections, but they don't export any JS classes: Compiler warning: Exported declaration uses non-exportable parameter type Kotlin/kotlinx.collections.immutable#172
• There's a multiplatform Firebase maintained by GitLiv here: https://github.com/GitLiveApp/firebase-kotlin-sdk. It implements most of the SDK, not sure how hard it would be to migrate auth etc, but might be worth a look.

[gino-m]

@jcqli Moving out of this iteration for now since we punted on this.