Don't return error response when clientError is a pipelined HPE_INVALID_METHOD

[kanongil]

This PR fixes the specific issue in #4363.

This is done by specialcasing clientError errors with code HPE_INVALID_METHOD that have an active request. Since the active request definitely has a valid method (otherwise it would not have passed through the router), this error originates from request data that is supposed to relate to the next request. As such, it should not respond with an error, but with the normal response. A hook is installed to make the connection close once this has been delivered.

Since the existing test suite only exercises this with err.code === 'HPE_INVALID_METHOD', I have added an extra test to exercise it with err.code === 'HPE_INVALID_CHUNK_SIZE' to keep the code coverage at 100%.

I also made a minor cleanup to request._finalize() and request. _setResponse(). _finalize() seems to somewhat assume that any non-Boom this.response object is a Response, when it can also be a Symbol.

Note that ideally, the current request should add a connection: close header, to indicate that it will close the connection.

Closes #4363. Closes #4364.

[kanongil]

Side issue: The CI doesn't actually test on node 18, even though it is the only fully supported node release!

I don't know why the macOS tests fail. They fine work locally.

[Marsup]

Is it ok to chain end and destroy on a stream like that? I would expect destroy to be hooked to an event or something.

[kanongil]

Right you are @Marsup. I don't know why I wanted the extra destroys… They are gone now.