Multi-Content Revisions/Revision Retrieval

For accessing the content of the different slots of a revision, a RevisionContentLookup service is defined:

For virtual slots, RevisionContentLookup::getRevisionSlot or RevisionSlot::getContent would generate the desired information on the fly. In general, RevisionSlot::getContent should be considered to be potentially expensive, since it may trigger lazy loading of the content blob.

Side note: the use of Title in this interface is unfortunate. We would want somethign more light weight, like TitleValue, but with the information from the page table, most importantly the page ID. A PageEntry or PageRecord, prehaps.

TBD: Shall we use the full Conent interface also for derived content, or should we define a more narrow interface, with only simple methods like getModel and isEmpty?

The initial implementation of RevisionContentLookup would just be a re-factoring of the current functionality. No schema changes are needed in the database. Only the main slot (and virtual slots) are supported. Implementation steps:


 * Move storage layer code for accessing revision content from Revision into RevisionContentLookup and an appropriate RevisionSlot implementation.
 * Change Revision to use a RevisionSlot to access revision content.
 * The initial implementation of RevisionContentLookup and RevisionSlot will rely on information from the revision table to provide meta-information about the main slot. Later, that information would be moved to a different storage schema.

To allow virtual slots to be defined, a dispatching implementation of RevisionContentLookup can be used. It would delegate to other specialized implementations of RevisionContentLookup based on the slot name and/or content type. This way, suitable RevisionContentLookup implementations can be created to e.g. provide access to the ParserCache, or RESTbase services, or use the new VRS infrastructure to provide information about revisions.

Storage layer code dealing with revision meta-data should also be moved from the Revision object to an implementation of RevisionLookup. That information would be modeled by a new "dumb" data object called RevisionRecord or some such. The definition of the RevisionLookup interface is relevant to this proposal, but it does not need to be implemented right away. Just to give an idea: