Avoid using functions deprecated in OpenSSL 3.0

[cgutman]

Description

This PR fixes deprecation warnings in crypto.cpp due to use of legacy low-level SHA256/RSA APIs. I have replaced these with the high-level EVP equivalents as suggested by the OpenSSL 3.0 migration guide.

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update (changes to documentation)
• Repository update (changes to repository files)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[cgutman]

There are still deprecated functions in use in the Simple-Web-Server submodule. If you fork that into the LizardByte org, I can submit a PR to fix those too.

[ReenigneArcher]

Should we try to use the original Simple Web Server instead of trying to maintain a fork? It seems to still be actively developed. https://gitlab.com/eidheim/Simple-Web-Server

I've also forked Loki's fork, here: https://github.com/LizardByte/Sunshine-Simple-Web-Server

[cgutman]

It looks like some of the things we needed to patch in (like local endpoint address info) are now available upstream.

We may still need some out-of-tree patches, but we should at least rebase our fork on upstream. I'll play with the upstream repo and see what it takes to make it usable for us.

[ReenigneArcher]

Perhaps change the submodule to point to upstream, and then we can apply any required patches similar to this (https://github.com/LizardByte/build-deps/pull/18/files) where needed?

[cgutman]

It turns out that we can actually migrate to the upstream version without needing any patches. See #517.