We add the macs for the provider as wrappers around the EVP_MD
implementations designed for ENGINEs.  This is not the most elegant,
but it does the job.

When an algorithm has an OID, it's included in the OSSL_ALGORITHM name
as an alias.  This is the way to avoid having to register the OIDs in
OpenSSL proper.

We add the digests for the provider as wrappers around the routines
designed for ENGINEs.  This is not the most elegant, but it does the
job.

When an algorithm has an OID, it's included in the OSSL_ALGORITHM name
as an aliase.  This is the way to avoid having to register the OIDs in
OpenSSL proper.

test/01-digest.t is modified to test the provider as well.

We add the ciphers for the provider as wrappers around the routines
designed for ENGINEs.  This is not the most elegant, but it does the
job.

When an algorithm has an OID, it's included in the OSSL_ALGORITHM name
as an aliase.  This is the way to avoid having to register the OIDs in
OpenSSL proper.

test/03-encrypt.t is modified to test the provider as well.

This makes space for provider tests.

As a beginning, test/00-provider.t is added.  It corresponds to
test/00-engine.t.

All other test/*.t are currently skipped unless the engine is tested.
They will be re-enabled as support for each algorithm type is added in
the provider code.

This adds the source to get a minimal provider that provides...
nothing.

The gost provider is planned to be a wrapper around the already
existing functionality, designed for ENGINE use.

The easiest way to do this is to let the gost ENGINE continue to exist
within the gost provider, as an internal ENGINE.  To do that, we make
it possible to build gost_eng.c so it only populates the GOST ENGINE
structure, but doesn't perform any of the ENGINE registration.  That
way, the GOST ENGINE structure becomes purely internal, and can be
used as the actual implementation of the offered provider functionality,
through diverse EVP calls that accept an ENGINE pointer.

The error source files, e_gost_err.c and e_gost_err.h, are not
suitable for providers as they are, so we need to move those away from
the core library, and leave it to the provider code to deal with it.

* Don't recreate GOST EC groups every time

For multiple keygen it saves 6% time

...in DN output

MacOS ld doesn't support -rpath, so we must be able to not use it there.

Now that .github/before_script.sh works properly on MacOS, there is
no reason not to use it for this job as well.

It makes sure to install it where site perl scripts should be located.

Fix #346

Cmake 3.0 was a switch to using targets and properties rather than
variables when linking different components together.
We follow that philosophy by dropping ${OPENSSL_CRYPTO_LIBRARIES} and
${OPENSSL_SSL_LIBRARIES} in favor of OpenSSL::Crypto and OpenSSL::SSL.

Cmake is generally good at tracking specified dependencies between
libraries.  All that we need to do is to establish a dependency on
OpenSSL's libcrypto for 'gost_core', and then we can reduce the amount
of repeated dependencies for everything that links against 'gost_core'.

The static OpenSSL libraries have some dependencies that need to be
recorded fofr everything that's linked against it.  To achieve this,
we use ${OPENSSL_CRYPTO_LIBRARIES} and ${OPENSSL_SSL_LIBRARIES}
instead of ${OPENSSL_CRYPTO_LIBRARY} and ${OPENSSL_SSL_LIBRARY}.

OpenSSL commit https://github.com/openssl/openssl/commit/74b7f339aa58af57c0e71b7efca66e6f2db5ae2e
changed the default installation path on 64-bit systems.

The recommended workaround is appending --libdir=lib

More earlier versions don't properly detect OpenSSL 3.0.
BTW, workarounds still exist

Merge branch 'update-codeql-analysis' of https://github.com/levitte/engine into levitte-update-codeql-analysis

These days, the OpenSSL cmake package finder is capable of finding
a custom OpenSSL installation with no OPENSSL_ROOT_DIR defined, but
CMAKE_PREFIX_PATH defined.

However, gost-engine's CMakeLists.txt does use OPENSSL_ROOT_DIR, so
it needs it to be defined unconditionally.  That's arranged fairly
easily by assigning it the parent directory of OPENSSL_INCLUDE_DIR.

Most of all, at least openssl-3.0.0-alpha16 is needed, because there
are API changes made in that release that affects gost-engine builds

The C flags were set to be highly optimized regardless of the cmake
build type.  This may make debugging difficult.  To resolve that, we
adapt the C flags to the cmake build type in a supported manner.

(cherry picked from commit 1b684f3f)

This test is so internal that it doesn't even need the engine.

The following programs had a hard coded load of the gost engine.
This changes them to rely more on the testing environment, and to
load engines through configuration files.

This affects: test_ciphers.c, test_context.c, test_derive.c,
test_digest.c, test_params.c, test_sign.c, test_tls.c

It's not right to have segmentation faults.