Non-unique IDs for tasks in different jobs cause tasks to be overwritten in local DB

[gino-m]

This leads to various odd behaviors, like jobs not showing up as "free form" data collection, or jobs having no tasks.

Instead, we should avoid using UUID as PKs in the local db. Instead, we can generate unique numeric IDs, or prevent non-unique IDs in the local DB.

This problem will go away if we serialize the survey as a binary proto in the local db.

[scolsen]

Note from Gino: we should work toward using protos in the local db as well. It would be more valuable to fix this temporarily via destructive changes and to work toward leveraging protos instead.

[gino-m]

I propose the following solution long-term:

• [ ] Serialize survey and jobs as protos in two tables in the local db, eliminating the Tasks table entirely.
• [ ] Use synthetic IDs as PKs in the tables, make UUIDs indexed string fields (e.g., Jobs will have survey_id, job_id, and data columns, the latter storing the serialized Job proto).

[gino-m]

@scolsen Using protos everywhere is a much larger project. A patch is low priority here since this is a degenerate case which would only happen if someone accidentally manually adds to jobs with the same IDs. Moving to Icebox.

[kenstershiro]

Unassigning @scolsen and removing from the current iteration, based on latest comments

[gino-m]

@scolsen @anandwana001 Can you confirm that tasks with the same ID in different jobs will no longer break the local db?

[gino-m]

Simple solution: use both survey and job UUID when syncing in local db.

[gino-m]

Demoting to P2 since this won't happen unless we add a duplicate job ID by hand server side.