When deploying UrlShortener, we will undeploy ShortUrl, but we still need those urls to work. So add support to UrlShortener to read from the shorturl database and handle thoseNOTE: This is a proposed outcome for {T187045}.
------Before a wiki can switch from ShortUrl to UrlShortener, the ShortUrl extension first needs to gain a feature to keep the exsiting URLs working. There are also a number of user interface improvements and transitional optoins needed during the migration.
### Discovery for new short URLs.
NOTE: This is a proposed outcome for {T187045}.{T288653}
* [x] https://w.wiki features a URL creation form.
* [x] Special page enabled on local wikis, warning-free.
* [x] Promote local Special page on [Special:SpecialPages](https://en.wikipedia.org/wiki/Special:Specialpages).
### Discover short URL for current article when reading
The "ShortUrl" extension promoted the URL under the page title. This was cheap to do as the URLs were deterministic. We may not be able to do this from a performance perspective (T107188#6275214) and it may not be desirable design-wise, but we can instead expose an affordance in the sidebar toolbox.
* [x] {T289999}
* [ ] {T267921}
### Migration plan
Drafted by @Ladsgroup, @Legoktm, and @Krinkle:
* [ ] ShortUrl: Implement a new read-only mode.
* [ ] On wikis that use ShortUrl, set it to read-only and hide its UI. Turn on the new UrlShortener sidebar UI instead.
* [ ] ShortUrl: Remove code for UI, remove code for writing to the database.
* [ ] UrlShortener: Import read code for `Special:ShortUrl`, remove from old extension. Leave the now-empty repo deployed as-is for at least one week. Apache configuration rewrites remain as-is as well.
* [ ] ShortUrl: Undeploy (no-op).
* [ ] ShortUrl: Archive repo.