Can't use it as is right now. The proxy is commented out in
`BraveContentBrowserClient::CreateWebSocket`.

Chromium changes:

https://chromium.googlesource.com/chromium/src/+/c570adabe2a390ad16b8bbab2b9ffdd864ff7156

commit c570adabe2a390ad16b8bbab2b9ffdd864ff7156
Author: Yoichi Osato <yoichio@chromium.org>
Date:   Tue Jun 4 05:28:31 2019 +0000

    [websocket] Reland: "Split interface mojom::WebSocketClient"

    This CL splits the interface to two parts so that WebRequestProxyingWebSocket or
    extensions proxy only handshake of WebSocket:

    interface WebSocketHandshakeClient {
      OnStartOpeningHandshake(WebSocketHandshakeRequest request);
      OnFinishOpeningHandshake(WebSocketHandshakeResponse response);
      OnAddChannelResponse(string selected_protocol, string extensions);
    };

    interface WebSocketClient {
      OnDataFrame(bool fin, WebSocketMessageType type, array<uint8> data);
      OnFlowControl(int64 quota);
      OnDropChannel(bool was_clean, uint16 code, string reason);
      OnClosingHandshake();
      OnFailChannel(string reason);
    };

    Performance gain of receive-arraybuffer-1MBx100.html:
    Mine: 1050 ms
    ToT : 1221 ms

    Relanding:
     The previous patch was reverted because of a browser test
    of "--disable-features=NetworkService". This patch fixes it to adapt
    a WebRequestAPI test to both expectations.
     Reverted-change: https://chromium-review.googlesource.com/c/chromium/src/+/1628497

    Bug: 865001, 942989

https://chromium.googlesource.com/chromium/src/+/7ce089524dc096357034700d2e5b76ff29d50388

commit 7ce089524dc096357034700d2e5b76ff29d50388
Author: Yoichi Osato <yoichio@chromium.org>
Date:   Tue Jun 18 02:10:34 2019 +0000

    Reland "[WebSocket] Add --websocket-renderer-receive-quota-max command line flag."

    Reason for reland: the culprit was not this patch.

    This patch was reverted because of compile failure on android:
    https://chromium-review.googlesource.com/c/chromium/src/+/1660391

    However, relanding this don't cause compile failure.

    Bug: 865001

commit 04d43cf58c3473d83adfed27fb8dcb2ead6f4c3a
Author: Yoichi Osato <yoichio@chromium.org>
Date:   Fri Jun 14 04:04:21 2019 +0000

    [WebSocket] Add --websocket-renderer-receive-quota-max command line flag.

    This patch adds the flag that overrides default threshold value
    that the renderer calls AddReceiveFlowControlQuota() to the browser per
    receiving this amount of data so that the browser can continue sending
    remaining data to the renderer.
    Default value is 32k Bytes.

    The more the value is, browser tends the less stop sending packets
    and then consumes more memory.

    This flag will be used to investigate the performance issue.
    You can use this flag both on chrome and content_shell:
    $ ./chrome.exe --websocket-renderer-receive-quota-max=3000000
    This flag sets the threshold 3M Bytes.

    Implementation detail:
    This patch moves the default value constant from blink to
    net/websockets/websocket_channel.h so that we can pass the command line
    flag to the renderer.
    This change also enables us to modify the value while considering sent buffer
    from a server later on for further optimization.

    Bug: 865001

https://chromium.googlesource.com/chromium/src/+/6894c69a9c069d2175794c8d11743298dddd65cf

commit 6894c69a9c069d2175794c8d11743298dddd65cf
Author: Yutaka Hirano <yhirano@chromium.org>
Date:   Fri Jun 28 12:54:45 2019 +0000

    Rename WebSocketHandshakeClient messages

    In preparation to removing AddChannelRequest, rename AddChannelResponse
    to OnConnectionEstablished. OnFinishOpeningHandshake has been confusing
    because it doesn't mean successful handshake finish (i.e., connection
    establishment). Rename it to OnResponseReceived. Rename
    OnStartOpeningHandshake to OnOpeningHandshakeStarted for consistency.

    Bug: 967524

https://chromium.googlesource.com/chromium/src/+/8e0b4d43cebd21a0be442187fe33d325939857e1

commit 8e0b4d43cebd21a0be442187fe33d325939857e1
Author: Yutaka Hirano <yhirano@chromium.org>
Date:   Thu Jul 4 07:12:38 2019 +0000

    Remove mojom::WebSocket::AddChannelRequest

    ...in order to remove the unnecessary overhead on the browser process
    when downloading / uploading payloads. With this CL, both
    mojom::WebSocket and mojom::WebSocketClient only pass though the proxy
    interface implemented in extensions/browser/api/web_request.

    With this CL,

    1) NetworkContext::CreateWebSocket takes additional parameters. This
    makes the state transition in network::WebSocket a bit simpler.

    2) blink::mojom::WebSocketConnector is introduced.
    mojom::WebSocketConnector::Connector corresponds to
    mojom::WebSocket::AddChannelRequest.

    3) mojom::WebSocket is passed as a parameter of
    mojom::WebSocketHandshakeClient::OnConnectionEstablished.

    4) Instead of mojom::WebSocket, the extensions module now receives
    a function to initiate a WebSocket opening handshake.

    5) ContentBrowserClient::WillCreateWebSocket is split into three:
    WillInterceptWebSocket, GetWebSocketOptions and CreateWebSocket. This
    incurs an additional thread hop, but it will be fixed once the
    extensions module for WebSocket is moved to the UI thread.

    This improves [1] in my environment.

    Without the change: 318MB/s
    With the change   : 389MB/s

    1: third_party/blink/perf_tests/websocket/receive-arraybuffer-1MBx100.html

    Bug: 865001, 967524, 942989