Add verbose, keepalive, keepidle, keepintvl to c-libcurl

[hirishh]

Hello,

I've added the keepalive functionality to c-libcurl.
It's implemented like in this example: https://curl.se/libcurl/c/CURLOPT_TCP_KEEPALIVE.html
This feature is available since libcurl 7.25.0.
I didn't implement CURLOPT_TCP_KEEPCNT because it was added only in libcurl 8.9.0

I took this opportunity to move also the verbose option in the new sslConfig_t struct accessible in the apiClient. In this way it can be programmatically activated (it's very useful instead of recompiling).

Technical Note: This configuration is meaninful with watch type of calls, but activating it to normal calls doesn't have any side effects.

About testing:
I regenerated the samples but apparently they are outdated (the c ones) and need to be fixed. I will try to fix them in a separate PR.
I've tested this code by modifying the generated code in the kubernetes-c library, as you can see here: https://github.com/kubernetes-client/c/pull/275/files

C Committee: @zhemant (2018/11) @ityuhui (2019/12) @michelealbano (2020/03) @eafer (2024/12)

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[hirishh]

I've fixed also the manual tests. They were a little bit outdated.
I've tested them with the petstore server via docker image.

[wing328]

https://github.com/OpenAPITools/openapi-generator/actions/runs/16473582128/job/46621036702?pr=21613

please update the samples when you've time

[hirishh]

Yep, updated and fixed. Sorry

[hirishh]

I have another proposal, just open for discussion: what about exposing directly the CURL *handle via a callback just before the curl_easy_perform(handle)?
In this way programmers have access to the curl handler and they can manipulate curl options as they want. This will remove the limits on usage on curl options that are available on different libcurl versions.

It will look like this:

typedef struct apiClient_t {
    ...
    void (*curl_pre_invoke_func)(CURL *);
    ...
} apiClient_t;

and on apiClient_invoke()

if(apiClient->curl_pre_invoke_func != NULL) {
    apiClient->curl_pre_invoke_func(handle);
}

res = curl_easy_perform(handle);

do you think it is a bad idea?

[wing328]

I have another proposal, just open for discussion: what about exposing directly the CURL *handle via a callback just before the curl_easy_perform(handle)?

sounds good to me.

i think some other clients (e.g. java, typescript) are already offering something similar to cater different use cases (fine tuning the request before sending it out).

[wing328]

thanks for the PR, which has been merged

have a good week ahead