refactor: DialogHandler

[david-allison]

Move serialisation + handling to classes instead of being spread around the codebase

Keep enum: WhichDialogHandler to ensure that we do not reuse int values

Pull Request template

Purpose / Description

• Our DialogHandler implementation split our two aspects of handling Messages (which isn't the easiest code to follow):
  • Serialisation around the codebase
  • Deserialisation + logic in DialogHandler

Related

• Makes Storage Migration: Sync before starting storage migration #13356 easier to understand, as we add another handler (without a dialog) here
• DialogHandler assumes it was started by DeckPicker, may crash otherwise #5075

Approach

• Split out each DialogHandler into a class: containing the method and the serde of its parameters
• Document the class a little better
• Use an enum to ensure that no items have duplicated what integers, and all cases are handled

How Has This Been Tested?

Unit test only

Learning (optional, can help others)

Finally documenting our use of Message: The implicit assumption is that we launch all of the dialogs from DeckPicker, and the notification uses an intent of DeckPicker, so everything should work. This assumption occasionally breaks down

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[mikehardy]

LGTM

[david-allison]

Rebased

[mikehardy]

A week is long enough for folks to have a chance, "go"!