deps: defer to pptr for devtools-protocol version

[brendankenny]

As mentioned in #12284, we risk issues with two sets of protocol definitions active in our type system. There's a performance issue (the types are big and we do lots of unioning and narrowing of them...having two of them would mean we'd also do type comparisons of the giant unions/narrowings of two different versions of the protocol), but if the types drift too much we'll also get type errors.

Those errors happen today at the fraggle rock session boundaries if you do yarn add -D devtools-protocol@latest to get the latest version of the protocol vs what's currently shipped in puppeteer (release from April 6).

I suggested in the last PR that if we are going to go all in on puppeteer for our protocol provider, then we should just defer to them for the protocol version. An easy way is to just use the same version number as them, which this PR is doing, but that's kind of annoying to remember to update every time we bump puppeteer (I guess we could add a CI check).

I was hoping another approach would be to have our version float on devtools-protocol@*, but yarn doesn't show any interest in updating that when you change the other version in the transitive dependency.

Anyone else have ideas or completely different approaches to stay in sync?

[brendankenny]

(this was just a drive by vulnerability-warning dependency update. We only use this for types for a devDep in viewer/treemap, but w/e dependabot)

[connorjclark]

Can we override the version puppeteer has to equal what we have?

"resolutions": {
      "puppeteer/**/devtools-protocol": "0.0.863986",
}

[brendankenny]

Can we override the version puppeteer has to equal what we have?

"resolutions": {
      "puppeteer/**/devtools-protocol": "0.0.863986",
}

yeah, I guess this is strictly better. It still requires looking in two places to keep things in sync, but at least this approach keeps everything in package.json and doesn't have one reference deep in yarn.lock :)

[brendankenny]

One issue is incompatibility with puppeteer types (e.g. a pptr function that depends on a particular protocol type that's not in our resolved version) but I don't know how probable that is. I guess we can see if we run into it.