http: ClientRequest.abort is destroy

[ronag]

ClientRequest.destroy() should be the same as abort(). Make ClientRequest more streamlike by deprecating abort().

If request has completed it cannot be aborted.

This also allows us to replace a lot of edge case code (e.g. isRequest) that has to call abort for ClientRequest while everything else is just destroy.

Calling destroy previously instead of abort might have some weird behaviour since abort seems to take a lot more stuff into account e.g. req.agent.

Refs: #28686

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

NOTE TO SELF: look into the callback

[ronag]

There is more work to be done (e.g. the TODO in this PR) in terms of making ClientRequest and OutgoingMessage more stream like. But I suggest that be done in future PR's.

[ronag]

Fixed failing test

[ronag]

ping @benjamingr

[ronag]

@Trott: This is no longer blocked

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/24908/

[ronag]

@Trott: this looks ready

[ronag]

@lpinca you good with this?

[lpinca]

RSLGTM

[lpinca]

I think this requires a CITGM run. The breaking changes are big enough.

[ronag]

RSLGTM

lol, what? :D

[lpinca]

Rubber Stamp LGTM :)

[ronag]

@Trott CITGM please

[lpinca]

CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1953/

[Trott]

Optional suggestion:

Suggested change

	[`ClientRequest.abort()`][]. Make ClientRequest more streamlike by deprecating
	[`ClientRequest.abort()`][]. Make ClientRequest more stream-like by deprecating

[Trott]

CITGM looks good but this does need a rebase.

[ronag]

@Trott: this is missing deprecation idx (i.e. DEP0XXX) which makes merging harder... 0daec61... is that a mistake?

[ronag]

I think #29192 is a much more elegant solution, although a bit more risky...

[ronag]

@mcollina, @lpinca (someone else?): unless you have an objection I would prefer to close this PR in favor of #29192.

@Trott: Otherwise, I would like to remove the change where we swallow any error after destroy()/abort() until the conversation in #29197 is resolved.

This PR needs mode thoughts.

[ronag]

Closing in favor of #29192 which should not be as controversial. Will open a new PR if required once there is consensus.