tree d892e51a3d8aba9fe40460c218b5e6a7d0928c27
parent 10645f31bf6f13d843c08baf157429576fbc5a17
author Ming-Ying Chung <mych@chromium.org> 1694601740 -0700
committer Chromium WPT Sync <blink-w3c-test-autoroller@chromium.org> 1694601740 -0700

[fetch-later] Add `FetchLaterParams` into network::mojom::URLRequest.

Sequence Diagram: https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ/edit#heading=h.y51nt9atd97v

- Replace `URLRequest::is_fetch_later_api` with
  `URLRequest::fetch_later_params`.
- Define `FetchLaterPrams`, which includes a pending_remote of
  FetchLaterClient.
- Define `FetchLaterClient`, which supports `SetFetchLaterHost()` and
  `Clone()`. The former should be implemented in blink to support
  Renderer->Browser communication.
- Define `FetchLaterHost`, which is implemented by every
  KeepAliveURLLoader. It supports a one-time method `SendNow()` and
  `Abort()`.
- Aborting a FetchLater request right after calling fetchLater(), and
  then disposing a page, can introduce race condition, such that the
  browser still send out the request. In KeepAliveURLLoader, it tries
  to mitigate this by looking into the custom disconnection reason
  from the remote of FetchLaterClient. But the race can still happen.
  OT info will include this problem.

See the "Renderer->Browser Communication" section [1] for the details
and other considered alternatives.

Subsequent CL https://crrev.com/c/4803283 will use this interface to
implement fetchLater()'s backgroundTimeout feature.

[1]: https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ/edit#heading=h.15fe7ufeo4uv

Bug: 1465781
Change-Id: Ib5067de1a10478cd0bb16ff6c4d981872bf5c1a6