[curl] add support for HTTPS proxy type

[jjlin]

Description

Added support for HTTPS proxies under Settings/System/Internet access.

The CURLPROXY_HTTPS type was introduced in curl 7.52.0 (December 2016).

Motivation and context

Provides users with the option to use HTTPS proxies in addition to plaintext HTTP and SOCKS proxies.

How has this been tested?

Tested on a Windows build by installing an addon and verifying via Wireshark that the addon download used the proxy.

What is the effect on users?

Added support for HTTPS proxies under Settings/System/Internet access.

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation (https://kodi.wiki/view/Settings/System/Internet_access)
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[jjlin]

I've made some formatting changes to meet the current code style. The diffs are available in the following links:

• PR21966-0001-8f848ddd47-curl-add-support-for-HTTPS-proxy-t.diff
• PR21966.diff

For more information please see our current code style guidelines.

This doesn't seem like an improvement to me (and I don't see anything in the style guidelines that says it should be formatted this way), but let me know whether this is just a suggestion or an actual requirement for merging.

[ksooo]

It’s a requirement.

[ksooo]

You need to squash both commits down to a single commit.

[jjlin]

You need to squash both commits down to a single commit.

All right, done.

I think it would be helpful if the docs would reflect the current state of expectations, as CONTRIBUTING.md does say "Code and cosmetic changes should be in separate commits", while the style guidelines suggest avoiding vertical alignment that might create superfluous diffs later on.

[ksooo]

the docs would reflect the current state of expectations,

The docs are part of this FOSS project as well and everybody is invited to contribute to it. :-)

[ksooo]

"Code and cosmetic changes should be in separate commits"

Every commit has to be aligned with project's clang-format rules.

I admit, the wording is not good. What is meant is that you should provide one commit per logical change, whatever this is. For example, if you apply a functional change to a file, this should be in one commit, and in case you found some other things in that file (logically unrelated to commit 1) you would like to change (e.g. code formatting, c++ modernization at places commit 1 did not touch), put those changes in another commit. This makes the code review far more easy.

[fuzzard]

Thanks for the PR.