In T293109, we're considering changing links in wikitext that "should" use HTTPS, where "should" means they currently use HTTP but the website supports and enforces HTTPS. The motivation being that it ensures Wikipedia will be acknowledged as the referrer that way under the strict "trict-origin-when-cross-origin" policy, which restricts referal information to secure HTTPS navigations.
For a lot of major sites, like bbc.co.uk, there is no need to mass edit wiki pages because those domains advertise HSTS support in addition to HTTPS, which means they are in public preload lists, and are thus automatically fixed by the SecureLinkFixer extension. This means the HTML already links directly to HTTPS.
However, the SecureLinkFixer extension currently applies this change to the HTML rendering only. The data is still recorded in the externallinks database table unchanged, and thus means Special:LinkSearch claims there are HTTP links. This is especially odd in the user interface of Special:LinkSearch itself, because the result list, being an HTML link, is itself also affected by SecureLinkFixer.
Example from https://en.wikipedia.org/wiki/Special:LinkSearch?target=http%3A%2F%2Fbbc.co.uk
Note how the HTTP search result is itself a link to HTTPS.
I suggest we update the extension to apply its transformation also to the link data (which means applying it earlier, or in both places, depending on the data flow). This comes with the caveat that if domains are added or removed from the HSTS preload list, it will take until the natural edit or RefreshLinks job from a common template for it to be reflected in the LinkSearch database, but by the very nature of the HSTS system (which requires a multi-year commitment) entries rarely change. Plus, one could argue this is a feature in that this "lag" is not unique to the link database, it accurately reflects what we actually link to on those pages. If the page hasn't been reparsed after an HSTS expansion, then both the rendering and the link database would still point to HTTP. (This seems better than the alternative of a link database that "magically" reflects what a link will become in a future update that hasn't been applied yet.)
In any case, the LinkSearch database allow end-users to submit search queries without a protocol, to find both HTTP and HTTPS links for a domain, so users can always find the data, no matter how we record it.