Wrap libcurl calls

[Hind-M]

Fix #159 It seems like we are using libcurl functions quite everywhere in the code base, so I don't think we can drop libcurl dependency. I'm opening the PR as a draft to have first feedbacks and discuss if this is how we want to do stuff.

TODO:

• [ ] Handle ssl_backend_t enum conversion to use outside powerloader.

[Hind-M]

@wolfv I am wondering if the powerloader user can choose the SSL backend when using the Context or is it something supposed to be handled internally? cc @JohanMabille

[Klaim]

@wolfv I am wondering if the powerloader user can choose the SSL backend when using the Context or is it something supposed to be handled internally?

We discussed this in a recent PR and the decision is purely based on which OS is being used, so it's fine if it's decided by powerloader. Basically we want to move that code from the mamba integration PR back to powerloader, probably just keeping the function deciding and calling it as the default value in the context options.

[wolfv]

Just to clarify, this SSL backend setting is only relevant for the case where we have a statically linked binary (micromamba). In other cases, the curl default works fine since ca-certificates are properly installed. In the micromamba case we're forced to use the system one.

It is useful to be able to select the SSL backend, because it also controls which certificate store is used (e.g. keychain on macOS or the Windows certificate store on Windows). Users in corporate environments often have some self-signed certificates that they use to access the internet via some proxy.

[wolfv]

So IMO being able to choose the backend with the Context, but leaving it nullopt by default is the way to go.

[Hind-M]

Ok! But then If we want to not expose ssl_backend_t enum, we would need to use some kind of equivalent enum related to the platform but independent from curl and which would be converted to the current curl enum within powerloader.