OpenSearch icons and updates can be fetched over cricuits for arbitrary domains

Moved from !1711 (comment 3266235).

#19741 (closed) resolved an issue where OpenSearch data was fetched over the catch-all circuit. The issue was resolved by:

1. The OpenSearch XML specification was fetched with the principal of the page that supplied the <link rel="search" /> reference.
2. Any follow up icons or updates use a principal with the origin set to the effective top level domain (eTLD) of the icon or update's url.

However, in the second case, the icon or update urls need not use the same eTLD as the original page. E.g. See my test site and its OpenSearch XML. The icon is wikimedia.org and the update url is example.org.

Scenario 1

A siteA.com provides an OpenSearch XML with an icon pointing to siteB.com/.

1. User visits siteA.com and siteB.com in different tabs.
2. The browser has given siteA.com circuit A, and siteB.com circuit B.
3. siteA.com has assigned a unique ID xyz1 to the user.
4. On the tab for siteA.com, the user uses the search bar to search with siteA.com's advertised search engine by selecting the "Search with site A" search action.
5. siteA.com returns the OpenSearch XML file over circuit A, with the icon set to siteB.com/xyz1/favicon.ico.
6. The browser requests siteB.com/xyz1/favicon.ico over circuit B. The unique ID is used to link the two circuits.

I.e. the activity on the two domains will be linked. This requires the two sites to collaborate, in which case they probably have better options to link activity. And it would require a very particular user behaviour. But ideally this would not be possible.

Scenario 2

Similar to the above, except the user installs the search engine for siteA.com using the url bar's search menu.

This is less bad because it is more likely to only happen once.

Scenario 3

Similar to Scenario 2, but the update url is set to some other domain. If the update is called, it can similarly link a user to the circuit of siteB.com, even when the siteA.com tab is not open. This would be worse because the unique ID could link the user between sessions without them using the search engine.

However, the updates are currently blocked by default, since browser.search.update is false in our base browser profile. Although, it does not seem to be set to false for this reason specifically. So maybe we should be locking this preference in the tor browser profile, or providing some context in a comment for the preference. Or we could disable it lower down by keeping the engine's updateURI empty.

/cc @ma1 @pierov