Refactor StudioEditableBlock's callbacks for editing & duplication

[kdmccormick]

Make studio_post_duplicate, editor_saved, and post_editor_saved real inheritable methods on StudioEditableBlock, rather than some getattr hackery, as suggested here: https://github.com/openedx/edx-platform/pull/7482/files#r27728847

Also, consider renaming:

• studio_post_duplicate -> studio_duplicate
• editor_saved -> studio_saving
• post_editor_saved -> studio_saved

[connorhaugh]

Re: the rename:
This will require time, because we have to assume xblocks we don't know about (other than Library,Video and SplitTest) might implement what is now known as editor_saved. How do we go about changing an unofficial-ish part of the xblock api safely?

[kdmccormick]

I would do a text search for the string editor_saved in the openedx org, recommend that someone at 2U do the same in the edx org, and lastly just mention the change in the named release notes.

I don't think DEPR or any other involved communication process is necessary here, since this was never a supported part of the public XBlock API.

[feanil]

It's important to remember that our APIs have not been historically strong so while people aren't supposed to use features, they still might be because of a lack of other options. It may be worth making and announcing the DEPR anyway if it's not significant overhead.

[kdmccormick]

Maybe. To get edx-platform to a good state, I expect that we'll need to make many dozens of changes to things that aren't public APIs but might be in use by somebody. One DEPR is not significant overhead, but dozens of DEPRs would be.

Perhaps batching the refactors together into big DEPRs could work, a la [DEPR] Several changes to how Studio renders XBlocks

[DanielVZ96]

Given that you also suggest renaming them, we could create new supported functions with those names and add a deprecation warning to the old ones. Then people can use the new inheritable methods when fixing the deprecation warnings.

Once there's a bunch of other DEPRs, they can all be removed at once in a singe big DEPR as suggested above.

[DanielVZ96]

Also I can start working on implementing the base functions while deprecation is still in discussion

[DanielVZ96]

@kdmccormick drafted the refactor here, please let me know if this looks like the approach you were looking for.

[kdmccormick]

@DanielVZ96 Cool, I'll take a look tomorrow and let you know.