OpenSSL strategy?

[dscho]

I think we should rethink our openssl/mingw-w64-openssl strategy.

Currently we maintain packages in Git for Windows Pacman repository that shadow MSYS2's versions of the same package. There are two reasons for that:

1. Historically, MSYS2 used to lag behind OpenSSL versions quite a bit. In Git for Windows, we needed to equip our users with secure versions relatively quickly. So we started to shadow MSYS2's packages by building up to date versions mere days after the OpenSSL announcements, not weeks or months. This situation has changed, actually reversed. These days Git for Windows usually lags behind further than the MSYS2 project, which is very active, having gained enthusiastic contributors who do a wonderful job at updating packages.
2. Nowadays MSYS2 does not offer any i686 variants of the MSYS packages anymore. That matters because OpenSSH still links to OpenSSL, and even though Git for Windows no longer offers full 32-bit installers, it bundles OpenSSH in its i686 flavor of MinGit.

In the interest of avoiding duplicate work that competes with MSYS2, and instead work closely together with that fantastic project and use all of our time wisely, I'm considering whether we can stop building OpenSSL in Git for Windows.

For x86_64/aarch64, we could simply switch to MSYS2's packages. For i686, we could keep building our own versions and stay on the v3.5.* train, which is supposedly good until 2029:

@rimrul @mjcheetham thoughts?