Don't allow access to geo question types if coarse (vs fine) location perms given

1. What is the general goal of the feature?
Ensure that usable location data is captured. Coarse/approximate location has 100m (city block) accuracy. This change will become relevant once ODK Collect targets Android 12 (more below).

When a user selects approximate location, we propose showing a dialog that describes why precise location is required and closing the form. They will get another opportunity to provide precise location next time they get to a geo question. After a certain number of failures to grant precise location, they will need to go to Android settings to answer geo questions.

Context: when ODK Collect starts targeting Android 12, users will be asked to choose between granting precise or approximate location permissions to ODK Collect. You can read more about the change in this article. The dialog users will be shown looks like:

From the usage we have seen, we believe approximate accuracy is never acceptable when capturing shapes or traces. We believe that while there are some cases in which 100m accuracy would be acceptable for points, projects generally best served by capturing as high accuracy of a point as they can and then may apply a post-processing step to anonymize the data.

Currently, ODK Collect crashes if "Approximate" is selected. :grimacing:

2. What are some example use cases for this feature?

A project leader is planning a project to get household-level information. They require precise coordinates of the households. This feature ensures that enumerators can't accidentally set their device to only capture approximate locations.

3. What can you contribute to making this feature a reality?

The core team and I are ready to address the current crash. We want to verify that requiring precise location for geo questions feels reasonable to users. Please let us know what you think.

I always want as precise as possible when collecting geo point information. I would be very curious to hear about a use-case otherwise. It's my understanding that this change would not affect how long a user might have to wait for a location fix (controlled for separately through things like capture-accuracy parameter), or the data file size (no difference between the 2 scenarios). As you mention, if there are data privacy concerns a post-processing step could be used (or they should maybe reconsider even collecting the data); I would think that relying on the device to do a poor job collecting the location should not be a data privacy methodology.