It fixes tests 1539, and 2402, 2404 (for non-Secure Transport), on macOS
with the gcc compiler.

Also unignore these tests in GHA/macos for non-secure transport.

Ref: c349bd6 #14097 (issue 15.)
Ref: 7b0240c #16539
Ref: 2ec0037 #16482

Closes #16580

To fix this test on macOS with the gcc compiler.

Also unignore test 1156 in GHA/macos.

Ref: c349bd6 #14097 (issue 15.)
Ref: 7b0240c #16539
Ref: 2ec0037 #16482

Closes #16579

Kitware/CMake@1b0c92a
curl/curl#16482

diff from jca (i added a comment to the patch), ok tb (implicit ok sthen ;)

Kitware/CMake@1b0c92a
curl/curl#16482

diff from jca (i added a comment to the patch), ok tb (implicit ok sthen ;)

To help applications do the right thing easier, change some enum values
into defines with L suffixes so that they get the corect type (long)
easier when used with curl_easy_setopt(). This also fixes a few of our
own libtests.

To reduce the risk that this change breaks the compile for any existing
users, the previously provided enums are still provided, but the values
to use are not defined by the enums.

This change "magically" fixes a few RTSP test failures we have had on
64-bit platforms because those options were not see using longs
properly.

Closes curl#16482

It fixes tests 1539, and 2402, 2404 (for non-Secure Transport), on macOS
with the gcc compiler.

Also unignore these tests in GHA/macos for non-secure transport.

Ref: c349bd6 curl#14097 (issue 15.)
Ref: 7b0240c curl#16539
Ref: 2ec0037 curl#16482

Closes curl#16580

To fix this test on macOS with the gcc compiler.

Also unignore test 1156 in GHA/macos.

Ref: c349bd6 curl#14097 (issue 15.)
Ref: 7b0240c curl#16539
Ref: 2ec0037 curl#16482

Closes curl#16579

Our macOS CI jobs execute on GitHub Actions runners, and in our
"build-earliest" job we compile a custom version of Git and run our
test suite with that version, which at the moment is Git v2.0.0.
We compile our custom version of Git against the version of the
curl library supplied by Homebrew on macOS GitHub Actions runners.

Recently, after Homebrew updated its version of curl to 8.13.0, our
"build-earliest" job been failing because the C compiler reports that
the CURLUSESSL_TRY identifier is not declared in the call to
curl_easy_setopt() in Git's get_curl_handle() function:

  https://github.com/git/git/blob/v2.0.0/http.c#L363

Between Git versions 1.8.3 and 2.33.8, that curl_easy_setopt() call
would only be compiled if the CURLOPT_USE_SSL macro was defined.
Fortunately, so long as curl v7.17.0 or later was in use, this was
always the case, but only because Git itself defined that macro,
not curl.  Under the same conditions and between the same Git versions,
Git also defined the CURLUSESSL_TRY macro that is now causing problems
when we try to compile Git v2.0.0 with curl v8.13.0.

Starting with commit git/git@4bc444e
in Git v1.8.3, Git's http.h source file included macro definitions of
the CURLOPT_USE_SSL and CURLUSESSL_TRY names.  These were set to the
values CURLOPT_FTP_SSL and CURLFTPSSL_TRY, respectively, so long as
the CURLOPT_USE_SSL macro name was not defined elsewhere and the
CURLOPT_FTP_SSL name was defined:

  https://github.com/git/git/blob/v1.8.3/http.h#L45-L52
  https://github.com/git/git/blob/v2.0.0/http.h#L44-L51

These macro definitions were preceded with the following comment:

  CURLOPT_USE_SSL was known as CURLOPT_FTP_SSL up to 7.16.4,
  and the constants were known as CURLFTPSSL_*

This comment specifically refers to the introduction to the curl library
of the CURLOPT_USE_SSL CURLoption enumerated constant in commit
curl/curl@9f44a95, and the introduction
of the associated CURLUSESSL_TRY curl_usessl enumerated constant in commit
curl/curl@3fa6016.

Both of these constants first appeared in curl v7.17.0, and replaced the
earlier CURLOPT_FTP_SSL CURLoption enumerated constant and CURLFTPSSL_TRY
curl_ftpssl enumerated constant, which were retained but were now defined
using macros that mapped those names to the corresponding new identifiers:

  https://github.com/curl/curl/blob/curl-7_17_0/include/curl/curl.h#L1140
  https://github.com/curl/curl/blob/curl-7_17_0/include/curl/curl.h#L510

Thus the intention of the macro block added to Git's http.h source file
in Git v1.8.3 was to check whether the new, generic CURLOPT_USE_SSL
option and associated CURLUSESSL_TRY curl_usessl enumerated constant
were defined, and they were not, define them in terms of their older
FTP-specific counterparts, if those are available.

However, curl has never defined identifiers such as CURLOPT_FTP_SSL as
macros.  Instead, macros named T(), CINIT(), and lately CURLOPT() have
been used to initialize the CURLOPT_* CURLoption enumerated constants.
See, for example:

  https://github.com/curl/curl/blob/curl-7_2/include/curl/curl.h#L172-L175
  https://github.com/curl/curl/blob/curl-7_17_0/include/curl/curl.h#L573-L582
  https://github.com/curl/curl/blob/curl-7_69_0/include/curl/curl.h#L948

These macros generate single enumerated constant assignments of the form:

  CURLOPT_USE_SSL = CURLOPTTYPE_LONG + 119

In other words, CURLOPT_USE_SSL has never been the name of a preprocessor
macro, and CURLOPT_FTP_SSL was not either until curl v7.17.0 when it
was redefined as a macro with the value CURLOPT_USE_SSL.

Thus the first condition in the conditional statement of Git's
macro block, namely !defined(CURLOPT_USE_SSL), has presumably never
had its intended effect because CURLOPT_USE_SSL has never been the name
of a macro.  The defined() macro operator only evaluates to true if the
name it is passed is defined as a macro, not as a regular C language
identifier.  Thus the expression !defined(CURLOPT_USE_SSL) would always
be true, since CURLOPT_USE_SSL has never been defined as a macro.

This means that other condition in Git's conditional statement,
defined(CURLOPT_FTP_SSL), exclusively controlled whether the block
was processed or not.  As mentioned above, since v7.17.0 curl has
defined CURLOPT_FTP_SSL as a macro, not an enumerated constant, so
the conditional would evaluate to true and the macro definitions in
the block would be processed.

Hence with curl v7.17.0 or above, Git would define the macros
CURLOPT_USE_SSL and CURLUSESSL_TRY with the values CURLOPT_FTP_SSL
and CURLFTPSSL_TRY, and the preprocessor would expand those names
to those values.  But because those values match macros defined by
curl, the preprocessor would expand them again, producing the values
CURLOPT_USE_SSL and CURLUSESSL_TRY, which are of course identical to
the names Git initially defined as macros.

However, the C preprocessor does not expand macros it has expanded
previously, to avoid infinite loops of expansions.  Per the GCC manual:

  "If a macro x expands to use a macro y, and the expansion of y refers
   to the macro x, that is an indirect self-reference of x.  x is not
   expanded in this case either."

  https://gcc.gnu.org/onlinedocs/cpp/Self-Referential-Macros.html

Fortunately, both CURLOPT_USE_SSL and CURLUSESSL_TRY are defined by
curl (since v7.17.0) as enumerated constants for the CURLoption
and curl_usessl types, respectively:

  https://github.com/curl/curl/blob/curl-7_17_0/include/curl/curl.h#L1008
  https://github.com/curl/curl/blob/curl-7_17_0/include/curl/curl.h#L497

So long as these names were ultimately defined by curl as non-macro
identifiers, the compilation of older versions of Git that defined the
macros CURLOPT_USE_SSL and CURLUSESSL_TRY would still succeed.

This situation has changed with curl v8.13.0 because commit
curl/curl@7b0240c replaced the
CURLUSESSL_* enumerated constants, including CURLUSESSL_TRY, with
macro definitions, for the reasons outlined in curl/curl#16539 and
curl/curl#16482:

  https://github.com/curl/curl/blob/curl-8_13_0/include/curl/curl.h#L931

The consequence for our "build-earliest" CI job is that with curl updated
to v8.13.0, as is now the case for the Homebrew version of curl installed
on macOS GitHub Actions runners, there are two conflicting definitions
of the CURLUSESSL_TRY macro.  The first definition now appears in curl's
header file, and as described above, older versions of Git provide
another definition in a macro block in the http.h source file, and
that block is processed because its conditional evaluates to true.

The duplicate definitions of the CURLUSESSL_TRY macro only produce
compiler warnings, in and of themselves.  However, Git's definition
supersedes curl's, and so the preprocessor first expands CURLUSESSL_TRY
to CURLFTPSSL_TRY (per Git's definition) and then expands CURLFTPSSL_TRY
back to CURLUSESSL_TRY (per curl's definition of CURLFTPSSL_TRY).
At this point, preprocessing stops, at which point the compiler expects
to find a C identifier with the name CURLUSESSL_TRY.  When it finds none,
an error results.

(Note that newer versions of Git do not define the CURLOPT_USE_SSL
and CURLUSESSL_TRY macros at all, so our other CI jobs are not affected
by the changes in curl v8.13.0.  The conditional block which defined
these macros was removed from Git's http.h source file in commit
git/git@5db9d38 of Git v2.34.0.)

To resolve the compiler error without raising our minimum supported and
tested version of Git from 2.0.0 all the way to 2.34.0, we instead
update our script/build-git script to patch older versions of Git's
http.h source file and comment out the conditional block which defined
the CURLOPT_USE_SSL and CURLUSESSL_TRY macros.  Since all modern
versions of curl define these identifiers, there is no need for Git to
define them, and as noted above, Git versions since 2.34.0 do not do so.