Add Kobo support as underlying mapping tool

[spwoodcock]

Is your feature request related to a problem? Please describe.

• We have ODK support already.
• Many communities are already familiar with Kobo, so we should probably support it.
• ODK and Kobo are very similar in functionality, surveys based on XLSForm spec (and I think supporting similar functionality to Entities etc).
• We never considered it until now, so the project creation for ODK was not made in a generic way (e.g. we could have wrapped pyodk functionality in our osm-fieldwork wrappers, with an option for Kobo instead, as they both use very similar functionality...).
• Kobo does not appear to have a Python client wrapper for it's API, so we need to manually use a package like aiohttp for requests.

Describe the solution you'd like

• Create a Python client library for the kpi server functionality we need:
  • Create project
  • Create Entity list (one
  • Create a form
  • Create a server user with scoped access only to a single project
  • Create a user to access the form (via QRCode)
• Add a workflow to project creation UI for Kobo, with in the HTMX templates.
• Submit the data to kpi at the end of the project creation workflow:
  • A server user must be provisioned and provided to the manager, once the project is created. This allows them to manage the project directly in kpi, after it's created in FieldTM (if they need to modify something).
  • An 'app user' that can access the form via Kobo Collect, which we can configure via QRCode ideally in the mobile app.
• Display a QRCode on the project details page, to access the form via Kobo Collect.
• The same setup as ODK + QField for FieldTM hosted vs self-hosted instance:
  • We provide a kpi server to connect with by default (ideally running in Kubernetes - does kpi have a helm chart?).
  • User can enter their own credentials, to connect to their own kpi server if they wish.

Key requirements of kpi for this to work

1. Must support Entities (containing geometries - javarosa strings) in some form, via XLSForm spec.
2. Must support editing two entity lists from a single form (new feature in ODK...).
3. Must have a REST API (or similar) for server operations.
4. Must be easy to self host, alongside the rest of the FieldTM stack (ODK Central + QFieldCloud), ideally with an already existing helm chart for Kubernetes.

Ongoing support requirements

• Any changes to the kpi API must be reflected in our Python client wrappers, so that project creation continues to work.
• Future changes to Kobo Collect to use a map-first vs a form-first mapping workflow must simply work from a user perspective - if Kobo aligns with ODK's plans on this.

[linear]

TECH-990