url: doc deprecate url.resolve

[legendecas]

Refs: #61776 (comment)

url.resolve was deprecated but the deprecation was revoked in #37784. Given that url.resolve depends on a deprecated insecure API, it should also be deprecated.

[richardlau]

We need to update doc/api/deprecations.md, especially since the prior deprecation is marked revoked.

node/doc/api/deprecations.md

Lines 2657 to 2686 in 27ec431

	### DEP0116: Legacy URL API
	<!-- YAML
	changes:
	- version:
	- v19.0.0
	- v18.13.0
	pr-url: https://github.com/nodejs/node/pull/44919
	description: \`url.parse()` is deprecated again in DEP0169.
	- version:
	- v15.13.0
	- v14.17.0
	pr-url: https://github.com/nodejs/node/pull/37784
	description: Deprecation revoked. Status changed to "Legacy".
	- version: v11.0.0
	pr-url: https://github.com/nodejs/node/pull/22715
	description: Documentation-only deprecation.
	-->
	Type: Deprecation revoked
	The [legacy URL API][] is deprecated. This includes [`url.format()`][],
	[`url.parse()`][], [`url.resolve()`][], and the [legacy `urlObject`][]. Please
	use the [WHATWG URL API][] instead.
	An automated migration is available ([source](https://github.com/nodejs/userland-migrations/tree/main/recipes/node-url-to-whatwg-url)).
	```bash
	npx codemod@latest @nodejs/node-url-to-whatwg-url
	```

[legendecas]

Updated doc/api/deprecations.md with history of #61644 as well.

[Renegade334]

Without #61776, this is actually an application deprecation introduced in v24.0.0. The versioning semantics are a bit tricky, but we shouldn't call this a doc deprecation if it's emitting warnings!

[MikeMcC399]

This has got a little confusing because of the mixture of issues and decisions about whether the software needs to conform to the documentation or the other way around.

I moved the documentation issue to #61816 and my suggestion is to retroactively document in this PR that #55017 (implicitly) introduced an Application deprecation (non-node_modules code only) for url.resolve(), since it depends on url.parse(), in v24.0.0.

[gurgunday]

lgtm

[MikeMcC399]

@legendecas

Have you been able to look at the suggestion to change this PR so that it reflects the deprecation change in v24.0.0 instead of tying it to a REPLACEME version? See also the @Renegade334 comment above.

The PR is currently marked with author readyPRs that have at least one approval, no pending requests for changes, and a CI started. so it looks like you are not intending to make any change.

[legendecas]

As comment #61780 (comment) mentioned, I think this PR no longer serves my original intention. So I'm going to close this.

[MikeMcC399]

@legendecas

As comment #61780 (comment) mentioned, I think this PR no longer serves my original intention. So I'm going to close this.

Were you intending to resubmit a PR for this subject? If not, I can offer to do this, based on your work in this PR and the comments received.

[legendecas]

@MikeMcC399 please feel free to go ahead!

[MikeMcC399]

@legendecas

please feel free to go ahead!

Thanks for your feedback! I didn't want to duplicate anything that you already had planned.

I've submitted #62002 now for this documentation change.