Patch slonik to close streams more reliably

[alxndrsn]

Closes #482
Closes #485
Closes #565

Incorporates backported fixes:

• Close underlying QueryStream on stream.destroy() gajus/slonik#360
• Prevent stream() throwing Error AND calling success callback (streamHandler) gajus/slonik#414
• pool: don't allow connection re-use after stream() gajus/slonik#420

[matthew-white]

I think we're hoping to ship the patched Slonik with the upcoming patch release. We'll release off the release branch so that we don't ship other commits in master. After the release, we'll merge release into master. (For what it's worth, patch releases are usually simpler than this one has been. Usually patch releases come pretty soon after the last major release, so there aren't as many differences between the release branch and master.) To add this PR to the patch release, could you target the release branch? You'll probably first need to rebase onto origin/release locally, then force-push.

[matthew-white]

The unit tests look good to me!

[alxndrsn]

@matthew-white this has been rebased onto current master to re-introduce the slonik QueryStream._destroy() patch with minimal other changes.

[alxndrsn]

Maybe worth including gajus/slonik#414?

[lognaturel]

Maybe worth including gajus/slonik#414?

Unless it's really complicated for some reason I think that's a good idea.

[alxndrsn]

gajus/slonik#414 has been incorporated

[lognaturel]

And this will fix master That change is at #635 and should probably be merged on its own.

Took a quick look, all looks like I expect, but I think it would be good for @matthew-white to take one last look since you two have all the context.

[matthew-white]

@alxndrsn, would you mind creating a PR to the central repo that specifies --legacy-peer-deps to npm ci? I think we'll need that in order to deploy this PR to a server.

[matthew-white]

I see that the PR description mentions that gajus/slonik#420 has been backported as well. That Slonik fix hasn't been merged yet, so I feel less sure about including that one. But it also seems OK to go ahead and merge: if we need to, we can always update our Slonik patch. Plus, we're hoping to ship #564 for the release.

I'm also unsure why import/no-extraneous-dependencies is being tripped. Do we need to configure or update eslint-plugin-import somehow? But also, there doesn't seem to be a lot of risk around these ESLint violations, so that question might not be worth digging into.

[alxndrsn]

I'm also unsure why import/no-extraneous-dependencies is being tripped.

I've double-checked, and it doesn't seem to be necessary 👍

[alxndrsn]

Won't reliably pass github-actions checks until #638 is merged