Add 'target browsing context' to requests.

[mikewest]

Currently, requests have a 'destination' property, which provides some
clarity about the type of request that's being made. For navigation
requests, however, we need a little more granularity in order to support
suggestions like #464 and #465. In particular, we need to distinguish
between navigation requests that target a new top-level browsing
context, and those that target nested browsing contexts (as the latter
are treated as subresource requests in the context of some policy
decisions).

This patch adds a new 'target browsing context' property to requests
which will be populated from HTML's navigation algorithm in order to
support these kinds of policies.

[mikewest]

Does this look reasonable, @annevk? If so, I'll follow up with an HTML patch to populate it.

[annevk]

We used to have something close to this and it got removed by @jungkees in fb87b70.

I wonder what @jungkees thinks. Another option would be to store this data on the environment, though I guess that's a little weird since the browsing context could go away whereas the environment continues to exist until collected.

[mikewest]

If I can get from a target client ID to a target client, great. In HTML, though, it looks like it's just an opaque identifier. Is there a mapping somewhere to hop from one to the other?

[mikewest]

Ping?

[jungkees]

Sorry that I missed this issue until now.

A target browsing context for a navigation is captured in process a navigate fetch step 4 (and the request's reserved client is set to that value in step 5.) The step 4 creates an environment that holds environmental states until the actual global object and environment settings object for fetched resource are created later (and set the corresponding states of the created environment settings object to them).

I'm curious if you need it before request's reserved client is set. If not, it'd be great if you could use the request's reserved client's target browsing context.

[mikewest]

@jungkees: I think that makes sense. It looks like reserved client is always set for navigational requests, and that its target browsing context should also always be set. That should be enough information for me, so I'll close out this PR.

Thanks!

[jungkees]

Sounds great!