noproxy: support for space-separated names is deprecated

[bagder]

To be removed in July 2024.

Fixes #10209

[michael-o]

I see two issues here:

osipovmi@deblndw011x:~/var/Projekte/curl (bagder/deprecate-noproxy-spacesep %=)
$ curl --verbose https://deblndw011x.ad001.siemens.net -k
* STATE: INIT => CONNECT handle 0x803d42808; line 1908 (connection #-5000)
* Uses proxy env variable NO_PROXY == 'localhost,.siemens.net .siemens.com .siemens.de'
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => RESOLVING handle 0x803d42808; line 1954 (connection #0)

• The message is only visible when --verbose has been provided
• The message is only visible when the parser has hit this, so not the entire string is consumed. See my mixed case.

But:

osipovmi@deblndw011x:~/var/Projekte/curl (bagder/deprecate-noproxy-spacesep %=)
$ curl --verbose https://deblndw011x.ad001.siemens.net -k
* STATE: INIT => CONNECT handle 0x803d42808; line 1908 (connection #-5000)
* Uses proxy env variable NO_PROXY == 'localhost .siemens.net .siemens.com .siemens.de'
* space-separated NOPROXY patterns are deprecated
* Added connection 0. The cache now contains 1 members

I guess both are intentional.

[bagder]

The message is only visible when --verbose has been provided

Yes. We have no habit of showing libcurl warnings more visible than this. I understand that this makes the warning a little hard to spot, but I think we can live with that.

The message is only visible when the parser has hit this, so not the entire string is consumed.

Yes, I realized this as well, but the parser does not go further than it needs to, so it does not know if there are space-separators later in the string, and adding an extended check solely for the purpose of adding the warning seemed like a like unnecessary.

[michael-o]

Both limitations are acceptable for me.