[WIP] Support renaming viewmodel classes in migrations

[chrisandreae]

If a viewmodel class changes name, migrations become a lot harder: clients specifying the old name in their X-ViewModel-Versions will be ignored, old client views won't be migrated up, and new server views won't be migrated down. This can only be partially mitigated by doing the migration in a parent view: it would have to use the parent view version change as a proxy for the child view+name change.

Instead, provide first class support for declaring that a migration changes a view's name with renamed_from :Foo

[thefloweringash]

LGTM, small number of comments.

[chrisandreae]

So there are two issues that are blocking this:

1: registering the historical names and versions in the registry at register/resolve_deferred_classes time is insufficient. The deferral is meant to be for long enough to a class to set the view_name. It's quite common within the body of a viewmodel class to end up hitting for_view_name and therefore resolving the deferred classes, including itself. If this happens before the migrates blocks, it'll be registered without any of its historical versions.

A possible solution to this would be to split the deferral in two, to resolve the class name and the historical versions independently. Then, migrates could validate that the latter resolution hasn't happened, effectively banning lookup of old versions (that would cause resolution) during the body of the class.

2: View aliases. Presently, alias names aren't registered at old versions at all, which is simply insufficient. But also, if a view has aliases, we don't know when they're valid from. We might have to extend the renamed_from to have multiple histories, and support something like renamed from: 'ParagraphView', to: 'NewParagraphView' to rename a non-default name. Then the old versions could be computed for all the alias names.

Alternatively, the alias names only exist for the MTI subclassing, which we don't like and wish we didn't have any more. If we were to implement #165, we could go ahead and release https://github.com/iknow/eikaiwa_content/pull/1598 which would remove the need for aliases, and we could drop that feature entirely.

[chrisandreae]

Alternative approach to (1) that would require less careful maintenance of the deferred structures:

Rather than the registry maintaining the full map of name -> version -> class, it could instead have

• a map of current-canonical-name -> class
• a map of historical-name -> [classes], sorted by descending highest version

At construction time you need to make sure there is no version overlap.
Then when resolving at a certain version, you take the first class that agrees that it responds to that version.
When resolving at no-version-specified, you only take the current canonical name.

Then because not all the version resolution is done eagerly, the only “deferred” step has to be adding the main class name, and that only needs to be deferred until the class name actually exists.

Alias names and historical names can be added immediately: at the time a view_alias call or a migrates { renamed_from: } is encountered.