Added chrome-side support for link rel=preconnect
This plumbs the blink preconnect support through to the existing
preconnect implementation exposed by the predictor. There was an
existing IPC for most of the plumbing that wasn't being used.
There was a bit of structural movement:
- Moved the IPC definition to the new network_hints component
- Renamed the IPC message to fall into a namespace used by network_hints
- Renamed the DNS prefetch IPC into the same namespace
- Added a connection count to the preconnect IPC
And the actual plumbing itself which mirrors the behavior of the DNS
prefetch plumbing where it queues the requests and posts a task back to
itself for submitting the actual requests at a later point.
It also counts preconnect requests for the same URL and uses that as an
indicator that more connections are needed (as many connections as
requests up to a limit of 6). This will only work if the URLs are
discovered after each other and before the scheduled task gets run which
will easily be the case for link tags that are grouped together but may
not be the case if they are scattered through the head (an acceptable
tradeoff). The net stack will de-dupe preconnect requests and just
leverage existing or pending connections which is why we need to
accumulate and count before requesting.
BUG=450682
Review URL: https://codereview.chromium.org/899883004
Cr-Commit-Position: refs/heads/master@{#315782}
CrOS-Libchrome-Original-Commit: ec1939d34edef32fbda9e2a6d3722749e343f5a8
diff --git a/ipc/ipc_message_start.h b/ipc/ipc_message_start.h
index 5305d22..8a9aba9 100644
--- a/ipc/ipc_message_start.h
+++ b/ipc/ipc_message_start.h
@@ -109,7 +109,7 @@
ExtensionUtilityMsgStart,
GeofencingMsgStart,
LayoutTestMsgStart,
- DnsPrefetchMsgStart,
+ NetworkHintsMsgStart,
BluetoothMsgStart,
NavigatorConnectMsgStart,
CastMediaMsgStart,