Requests for comment/image and oldimage tables

There's no auto-incrementing primary key for, and no primary key at all for. This should be changed so that we can uniquely and  performantly identify files and their revisions.

Problems

 * File revisions should have better unique identifiers than "current file title + timestamp" (subject to race conditions, hard to index, hard to query).
 * Files should not be identified by their caption, but be given a language-neutral identifier.
 * Uploading a new revision for a file should not involve moving the "current" row across tables and overwriting the current row.

Use cases

 * End-user improvements
 * Language-neutral file identifiers (see User:NeilK/Multimedia2011/Titles).
 * Allow embedding a file in a wiki page without depending on the current file name (e.g. references should not break after "renaming" or subject to redirects).
 * Remove need for globally unique "file titles" during uploads.
 * T139294: Persistent media links for file versions
 * Ability to potentially create secondary database tables that associate data with files or their revisions (e.g. T33257: File properties storage and License integration MediaWiki). This is not feasible in the current schema.
 * API Improvements
 * prop=imageinfo - Use revision ID instead of fragile timestamp as identifier.
 * Technical debt
 * LocalFile::recordUpload2 - Eliminate timestamp kludge.

1. Add primary keys
This solution is easier to implement and execute since it's a less drastic change.
 * Summary

The down side is that it keeps all technical debt, performance problems, and legacy infrastructure. There will still be no separation between entity and its versions, and there will still be needless separation between the current and older versions of a file.

Effective change Migration strategy Behaviour
 * Add  , , and   fields to the image and oldimage table respectively. (See Database layout.)
 * img_id: Primary key
 * oi_id: Primary key
 * oi_img_id: The value of img_id before the version was moved from image to oldimage
 * Create new fields and populate them with a script.
 * As before, creating a file revision requires atomic moving of the image metadata to the oldimage table, before the new current data can be overwritten.
 * When creating a file revision, set  to the file's former.

2. Separate entity and versioning
Eliminates the legacy handling of needing to interact with two tables for most operations (image and oldimage).
 * Advantages

Brings the file tables in line with the and  table. This will create proper semantic separation between file entities and the versions of their (mutable) content.

Effective change Migration strategy Behaviour
 * Add,  ,  , and   fields.
 * img_id: Primary key
 * img_latest: oi_id of the current version of an image (similar to )
 * oi_id: Primary key
 * oi_img: img_id of the image this version corresponds to (similar to )
 * (Optional) Rename oldimage to "imagerevision". Or, rename image to "file" and oldimage to "filerevision".
 * Create new fields and populate them with a script.
 * (Requires freeze?) Backfill file_revision with the "current" image data.
 * Metadata no longer lives spread over two tables.
 * Creating a file revision involves inserting a new file_revision row and updating the file.img_latest pointer.

3. Replace with MCR
Multi-content revisions as per T107595.

We could decide to stop using the image/file tables entirely, in favour of storing the information in the wiki page/revision tables. We'd obviously not store the file binary in the text table. But we could make file-backend references from there, similar to what we do with ExternalStorage already.

We could still keep a simplified image (or "file") table as secondary data (similar to "categories") - which would give us file IDs separate from page IDs, which may be useful. (Needs a solution to deal with selecting files cross-wiki, since page IDs would randomly conflict with using a foreign file repo.)