FLEDGE: Parallelizing bidding signals requests

[p-j-l]

As in #119, we're considering integrating FLEDGE with a flow that looks like:

1. The ad tag on the client sends a traditional contextual ad request.

2. It receives a contextual ad response, and also auction signals generated on the server, such as the estimated likelihood of the slot being viewable.

3. The tag invokes the FLEDGE APIs to run an interest group auction, providing those signals.

When combined with sending requests for trusted bidding signals, however, this gives unnecessary serialization, leading to higher latency and worse user experience.

After the call to runAdAuction, the browser will begin sending requests for trusted bidding signals (section 3.1). These requests depend primarily on information that the browser already has: the site, the browser's interest groups, the IG's trusted_bidding_signals_urls, and the IG's trusted_bidding_signals_keys. The only other input to these requests is the list of participating interest group owners, which we expect to typically be constant across a given site.

We want to propagate signals from the contextual ad response to the auction, so we can't invoke runAdAuction until it returns. This means bidding signals requests are unnecessarily blocked on the contextual ad response.

One way to resolve this serialization would be to add an optional call:

navigator.sendAdBiddingSignalRequests({
    'interest_group_buyers': ['www.example-dsp.com', 'buyer2.com', ...],
});

This would function as a hint to the browser that it can send bidding signal requests to these buyers. The responses would follow the same caching semantics as if they were triggered from within the auction, and be available to navigator.runAdAuction.

[JensenPaul]

I believe this was addressed in https://github.com/WICG/turtledove/blob/main/FLEDGE.md#211-providing-signals-asynchronously