On MacOS X, OpenSSL and cmake have different ideas on what suffix a
dynamically loadable module should have.  OpenSSL expects .dylib,
while cmake uses .so by default.

Fixed by explicitly telling cmake to use the same suffix as for shared
libraries.

'prove' is a well developed TAP harness program, there's no real need
to write one's own.

We do need to set certain paths properly for the appropriate 'openssl'
program to be run.  We do that with a 'prove' plugin (WrapOpenSSL.pm)
that simply amends the appropriate system environment variables, given
a number of cmake generated environment variables that indicate where
OpenSSL files reside.

This make that array uniquely belonging to the engine proper, while
leaving the more generic gost parameters functionality in the
gost_core library.

GOST_CORE_SOURCE_FILES and GOST_ENGINE_SOURCE_FILES were a bit
disorganised, they are now re-arranged so GOST_ENGINE_SOURCE_FILES
contains ENGINE specific source only, and what was less ENGINE
specific was moved to GOST_CORE_SOURCE_FILES.  Furthermore,
GOST_LIB_SOURCE_FILES now includes GOST_CORE_SOURCE_FILES, so the
gost_core library is complete with all implementations.

As a consequence, 'gost' is now explicitly made into a dlopenable
module.  On some operating systems, that makes a difference.

This paves the way for alternative implementations based on the same
base code, such as a provider implementation.

It's quite possible that the re-arrangement done here isn't "pure"
enough.  Future development will tell.

All, excluding ppc64le/s390x/ar64 architectures, macOS,
and Coverity run.

If at the input of the encryption function in the CFB mode we have
an integer number of blocks, then in the main loop all blocks will be
processed, except for the last one due to an incorrect border check.
The last block will be fully processed as a "partial" remainder, but
the initialization vector will not be updated. And, thus, the value
of IV will always be incorrect in this case.

This breaks stateless protocols due to an invalid initialization vector:
all messages except the first cannot be decrypted. (Naturally, we are
talking about a case with disabled key meshing, which does not allow
context recovery due to an erroneous implementation.)

It is worth noting here that the code for processing partial blocks
(both at the input of the encryption functions and at the output) is
a historically unnecessary artifact, since we do not set the
EVP_CIPH_FLAG_CUSTOM_CIPHER flag and, as a result, OpenSSL processes
partial blocks for us.

This patch corrects the checking of the main loop boundary.

A similar error is present in the code for the CNT mode, but there it
does not manifest itself in any way, because the restoration of the
state in this mode is impossible: even after disabling key meshing, we
still have the state-dependent transformation of the IV.

As an extra result of this fix, the code for processing partial blocks
can be completely removed now.

(cherry picked from commit cf402dd4)

Fixed bug when acpkm key meshing didn't apply at appropriate time
during TLS secure exchange.
Unify usage of 'num' variable of EVP_CIPHER_CTX for kuznetchik and
magma.

modernize magma & kuznechik ctrl functions for EVP_CTRL_TLSTREE mode.
add some minor updates to store master key for using in magma TLSTREE mode.

OpenSSL 3.0 deprecates function codes and ERR_PUT_error() in favor
of ERR_raise() and ERR_set_debug().

/root/rpmbuild/BUILD/openssl-gost-engine-1.1.1/CMakeFiles/CMakeTmp/src.c:4:14: warning: initialization of 'int *' from incompatible pointer type 'char *' [-Wincompatible-pointer-types]
    4 |     int *p = buf + 1;
      |              ^~~
/root/rpmbuild/BUILD/openssl-gost-engine-1.1.1/CMakeFiles/CMakeTmp/src.c:5:14: warning: initialization of 'int *' from incompatible pointer type 'char *' [-Wincompatible-pointer-types]
    5 |     int *q = buf + 2;
      |              ^~~

Reported-by: Ilya Shipitsin <https://github.com/chipitsine>
Fixes: #288

Note, you will need to pass `-lsocket -lnsl` to the gcc for
socketpair(3SOCKET) to link `test_tls'.

This is based on AX_CHECK_ALIGNED_ACCESS_REQUIRED from autoconf-archive.

Note, that on some arches unaligned access behavior could be changed at
runtime via prctl(1). Also, unaligned memory access is still slower (and
very slow on some arches) even if it's not strictly required.

Plus some minor style fix