lib: CURL_GLOBAL_WIN32 -> CURL_GLOBAL_WINSOCK

[jay]

• Change curl_global_init flag name from CURL_GLOBAL_WIN32 to CURL_GLOBAL_WINSOCK.

• Retain CURL_GLOBAL_WIN32 as an alias for legacy reasons.

• Remove lwIP initialization from CURL_GLOBAL_WINSOCK.

Prior to this change lwIP init was controlled by the flag which did not make sense. It may have some historical reason but if it does then that should be represented by a different flag. AFAICT lwIP init is not our responsibility, since it may need different init depending on how it is used.

The name change WIN32 -> WINSOCK is to eliminate user confusion. The name WIN32 may imply a broader Windows initialization, which libcurl always does and is not controlled by this flag.

Reported-by: Viktor Szakats

Ref: #22813 (comment)

Closes #xxxx

[vszakats]

This looks fine to me, arguably clearer than my iteration, and braver by
dropping lwIP from there (which I think is fine.)

Minor downside is that the name is still Windows-specific, and if there
ever comes a need to initialize another socket subsystem, we'll need
a separate macro. But with not such case in sight, I think this is fine.

Two suggestions:

1. Perhaps add the /* for compatibility */ comment to the WIN32 macro.
2. Possibly update the ## CURL_GLOBAL_DEFAULT section as in
   global_init: replace CURL_GLOBAL_WIN32 with CURL_GLOBAL_SOCKET #22813: https://github.com/curl/curl/pull/22813/files#diff-23d88334098b326478e029153f8e80cbd105a1359ad05f0cc65b977639179feaR106

[jay]

Minor downside is that the name is still Windows-specific, and if there
ever comes a need to initialize another socket subsystem, we'll need
a separate macro.

Yes but do you understand my position that it has to remain a Windows-specific flag because it was already documented that way. If we were to rename it CURL_GLOBAL_SOCKET and expand it so that it had some functionality on other platforms that would affect anyone already using the flag under the presumption in the doc. It's too late to change it in that way.

Two suggestions

added

[vszakats]

Minor downside is that the name is still Windows-specific, and if there
ever comes a need to initialize another socket subsystem, we'll need
a separate macro.

Yes but do you understand my position that it has to remain a Windows-specific flag because it was already documented that way. If we were to rename it CURL_GLOBAL_SOCKET and expand it so that it had some functionality on other platforms that would affect anyone already using the flag under the presumption in the doc. It's too late to change it in that way.

It limits future use to cases where we also want the initialization
to occur by default. Hard to say if this is better or worse without
a thing in sight to add. But I get your point, with a separate flag
we can decide at that point by either adding it or not the
DEFAULT/ALL value. I agree it's better this way.

Two suggestions

added

Thanks!

[jay]

If there are no objections to this I will land it in a few days.