[navigation-error-logging] remove "navigation" requirement?

tl;dr: I propose we remove "navigation" from Navigation Error Logging.

The original and the new drafts of NEL have been scoped to "navigation
requests" with the premise that a failure during the navigation sequence is
not observable and can't be logged by the application. By contrast (our
current premise) the application *can* observe subresource failures - e.g.
once the page loads the application can instrument subsequent fetches and
listen to onerror callbacks, etc. Hence, we scoped NEL to navigations only.

However, as I'm iterating on the spec, its becoming more and more clear
that the above premise is not true and is, in fact, very limiting:

a) The application can observe failures (e.g. onerror callbacks) of
subresource fetches, but it cannot get the same fidelity of information
about the failure - e.g. detailed DNS/TCP/TLS errors, etc.
b) A resource may belong to a "known NEL host" [1] but is embedded on a
third-party origin: if said resource fails to load there is no way for the
NEL host to know (or instrument, even), that a failure occurred.

The (b) case is particularly painful. Consider the following example:
widget.com provides a popular thing.js script that is embedded by many
sites across the web... User visits example.com that embeds the
widget.com/thing.js resource on its page but the resource fetch fails due
to a TLS error. Today, thing.js fetch falls outside of scope of "navigation
request": no report is generated, widget.com remains in the dark about this
issue... both example.com and widget.com are sad.

Given the prevalence of third-party resources (and the fact that they are
often a SPOF for many sites) the inability to address the above embedding
use case with NEL is a huge gap.

That said, the good news is, I think it's also easy to fix. We don't need
"resource error logging", I think we just need to drop the "navigation"
requirement from the current NEL draft. Everything else would remains the
same and we wouldn't need to define yet another alternative mechanism to
address (a) and (b) limitations described above.

Assuming "navigation" restriction is removed, the workflow for above
example would be:
(a) widget.com register an NEL policy
(b) user visits example.com with widget.com resource that fails to load
(c) user agent triggers an NEL report [2] to widget.com indicating an error

Thoughts, objections?

ig

[1]
https://w3c.github.io/navigation-error-logging/#policy-storage-and-maintenance
[2]
https://w3c.github.io/navigation-error-logging/#sample-navigation-error-report