In 1.1.1, to generate an SM2 key (in an EVP_PKEY), you would first create an EC
key (in an EVP_PKEY), and then call EVP_PKEY_set_alias_type() to convert it to
an SM2 key.

In 3.0 you are supposed to generate an SM2 key directly.

However, the CHANGES.md file seems to indicate that the old way should still
work - however it doesn't. Generating an EC key ends up with a provider side
EC key. Calling EVP_PKEY_set_alias_type() on a provided key will only work if
the "alias" type is the same as the actual type. Otherwise it fails. Therefore
legacy code will fail.

CHANGES says these things about it:

• Validation of SM2 keys has been separated from the validation of regular EC
  keys, allowing to improve the SM2 validation process to reject loaded private
  keys that are not conforming to the SM2 ISO standard.
  In particular, a private scalar k outside the range 1 <= k < n-1 is now
  correctly rejected.

• Deprecated EVP_PKEY_set_alias_type(). This function was previously
  needed as a workaround to recognise SM2 keys. With OpenSSL 3.0, this key
  type is internally recognised so the workaround is no longer needed.

  Functionality is still retained as it is, but will only work with
  EVP_PKEYs with a legacy internal key.

• Reworked the treatment of EC EVP_PKEYs with the SM2 curve to
  automatically become EVP_PKEY_SM2 rather than EVP_PKEY_EC.
  This means that applications don't have to look at the curve NID and
  EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2) to get SM2 computations.
  However, they still can, that EVP_PKEY_set_alias_type() call acts as
  a no-op when the EVP_PKEY is already of the given type.

  Parameter and key generation is also reworked to make it possible
  to generate EVP_PKEY_SM2 parameters and keys without having to go
  through EVP_PKEY_EC generation and then change the EVP_PKEY type.
  However, code that does the latter will still work as before.