doc: clarify IncomingMessage is a new Readable "forked" from the socket

[dr-js]

Refs: #36617

Added more description on the difference between the IncomingMessage and the underlying message.socket.

Added a separate commit to mark the change of v15.5.0 and deprecate message.aborted per #36617 (comment). (moved to #36670)

Checklist

• documentation is changed or added
• commit message follows commit guidelines

[aduh95]

This should add the deprecation info to doc/api/deprecations.md as well.

[targos]

Do we have a policy to treat doc-only deprecations as semver-minor?

[dr-js]

@aduh95 I wrote some test to compare current message.aborted behavior with message.destroyed at test-nodejs-message-aborted.js, and here is what I think:

Only directly call .abort() will emit the 'abort' event and set .aborted
to true, the .destroyed attribute will be set to true at the same time,
and the Stream 'error' and 'close' event will follow. Calling the Stream
.destroy() will emit only the 'close' event, and may not set the .aborted
to true.

So the abort related value and event is only useful for detecting .abort()
calls. For closing a request early, call the Stream .destroy() and listen for
'close' and 'error' should have the same effect and wider code support.

I'll add the second paragraph as the explanation.

Do we doc-deprecate event?
As currently request.abort() is marked, but the 'abort' event is not, so is the request.aborted kept.

Also it's better if @ronag could review the added explanation.

[ronag]

I think deprecation is something for a separate PR. I would personally be happy to doc deprecate:

• 'abort' event.
• 'aborted' event.
• .aborted property.
• .abort() function.

[dr-js]

@ronag then I'll split deprecation related commit to a separate PR and link back

[aduh95]

Landed in a5b43e9