COEP and CORP opaque responses

[annevk]

Talking with @domenic about #4764 I realized that the fix in #4734 would also affect ImageBitmap objects created inside a COEP process. In particular, there can still be opaque responses, but they're "CORP approved".

The main question here is whether origin-clean needs to become a tri-state or whether we accept that ImageBitmap objects that are not origin-clean cannot be deserialized inside a COEP process. I prefer the latter as the additional complexity does not seem worth it. In case you all agree this can be closed, unless there are more vectors I have not considered or you prefer an alternative design.

@whatwg/canvas @whatwg/security @mikewest @mystor @arturjanc @yutakahirano

(Making COEP require CORS would have been easier for this...)

[annevk]

I think I have a better solution which I'll put in the PR tomorrow. Namely, when serializing store the COEP state of the agent cluster and check that when deserializing and throw upon going from non-COEP to COEP. That way only the problematic case ends up failing and ImageBitmap created inside a COEP process from CORP opaque resources won't fail.

[annevk]

I still think that's the way to go and is the least invasive, so I'm going to close this, but please do reach out if you have concerns. This isn't set in stone (yet).