The implementation of trigger-on-download surveys is incredibly obscure

[biblicabeebli]

(creating an issue for this because the location of implementation for this feature is going to be forgotten)

• Trigger-on-download surveys are implemented as always-available surveys that don't get cleared from the list of active surveys.
• If you remove a trigger survey then it will reappear the next time the survey+main-screen-state code runs.
• Need to test to ensure that this current implementation does not keep resubmitting surveys. If that is happening then... will need to work out what to do.

new implementation brainstorm:

• (change code to remove trigger surveys from activeSurveys list and then....)
• add trigger-on-first-download surveys once, immediately after registration.
  • this would change the feature to be at-registration-time surveys, which is not the same as on-first-download surveys.
• Store a list of survey ids that were trigger-on-download surveys, make that a blocklist.
  • to make that a persistent object it would need to be stored on the study, which means extra database saves and crashes 🫠.
  • the code that activates surveys from push notifications (that takes a list of survey ids) should still work fine.
• and would need to then check whether a fully new survey is a trigger survey (e.g. build the logic one would expect).

(ok, that's a relatively huge lift for implementing such a feature, I guess the current implementation hack is way easier than that.)