Complete migration of FeedbackSession entities

[whipermr5]

Continuing work from #8094, #8410, #8456 and #8759, the script from #8759 can be run in the near future to migrate all FeedbackSession entities:

• This will finish up Feedback Session: Remove 'Never Publish' option #8468
• If the script is run after Remove private sessions #8447 #8518 is merged, it will finish up Remove private sessions #8447

After running the script from #8759, these tasks remain:

• Remove unused timeZoneDouble and wasFollowingCourseTimeZone fields (simple code deletion)
• Remove unused @OnLoad methods (simple code deletion)
  • convertFieldsToUtcIfRequired()
  • setTimeZoneFromCourseTimeZoneIfRequired()
  • populateMissingBooleansIfRequired()
  • adjustResultsVisibleFromTimeIfRequired()
• Change all boolean fields to primitives (FeedbackSession: use primitive type for all booleans #8451) (simple code edits)
• Remove isTimeStoredInUtc and isFollowingCourseTimeZone flags (another script needed)
• Simplify queries in FeedbackSessionsDb, namely getAllOpenFeedbackSessions and getFeedbackSessionEntitiesPossiblyNeeding(Open|Closed|Closing)Email
  • Investigate other queries that can be simplified (AdminSessions?)
  • This task is bigger and a new issue can be opened for it once the script is run

[whipermr5]

This will require load()/save()-ing ALL existing FeedbackSession entities in the datastore. @damithc when was the last time a migration of this scale took place? #6001? I'm wondering whether the existing client script framework is good enough; I suspect it will suffer from timeouts. I'm considering building a heavy duty client script framework that runs on the server itself via task queues - DataMigrationServlet. This way, the conversion will happen efficiently on the server and the data doesn't have to stream through a local machine.

For future reference: https://groups.google.com/d/msg/objectify-appengine/meUDiiUmD-Q/jm15CzBxym4J

[damithc]

@damithc when was the last time a migration of this scale took place?

We have nearly 30k session objects.
Yes, we need something more sturdy. Not sure if we should go serverside though. The problem is serverside requires a deployment and admin has less control during the migration process. In all past migrations I need to tweak the script along the way to deal with various 'dirty' data items i.e., not all data objects are in the exact format we expect them to be. There can be stray nulls, and so on.
Alternatives:

• make the script incremental e.g., run for sessions of one year at a time rather than all objects
• make the script repeatable e.g., if it times out, I should be able to rerun the script and it should skip over the entities already migrated

[xpdavid]

Related to #9044 to develop an new migration framework.

[xpdavid]

Done 🎉 Related issues created in #9125