Working on Multi-Content Revisions and discussing {T190063}, it became clear that the signature and contract of Content::getSecondaryDataUpdates would no longer work for the new multi-content logic.
In particular:
* only one LinksUpdate should be generated, and it should be based on the combined ParserOutput of all slots. Havign one LinksUpdate per slot would cause them to override each other.
* DataUpdates need to be aware what slot they refer to, to enable per-slot dependency tracking, and to avoid updates from different slots from interfering with each other.
Reason for having the new method in ContentHandler:
* The signature of the method in Content cannot be changed without breaking extensions (compare {T193613})
* Following the value/service pattern, much of the functionality of the Content interface should reside in ContentHandler anyway.
In addition to the new ContentHandler::getSecondaryDataUpdates, a similar method will be needed to get all DataUpdates associated with an edit. An implementation is currently proposed in If610c68f4 in the new DerivedPageDataUpdater class, but the method should be exposed via a more narrow (provider-like) interface (see T194043).