WL#17160: Support PBKDF2 storage format with Caching_sha2_password

To prepare against PQC scenarios, it is recommended that we double the hash 
sizes being used for password transformation.

The proposal is to support PBKDF2 with SHA512 storage format in 
caching_sha2_password. This provides following benefits:

1. Ability to switch default storage format in future without having to change 
authentication plugin
2. No client side changes needed
3. Migration path (from cryp5 to PBKDF2) without changing plugins

FR1: User should be able to choose PBKDF2 with SHA512 as storage format for 
passwords created with caching_sha2_password plugin.

FR2: It should be possible to change the preference of storage format at 
runtime. Any new password set (or reset) should take into account the latest 
preference of storage format at that time.

FR3: It should be possible to enforce storage format. User accounts that are 
using caching_sha2_password with another format(s) should still be able to login 
but forced to change the password which would change underlying storage format 
as well.
FR3.1: If format restriction is not enforced, user accounts that are using 
format other than the preferred one should continue to function without any side 
effects.

HLS1: Caching_sha2_password will be amended to support two storage formats.
- CRYPT5 with SHA256 (Existing).
- PBKDF2 with SHA512.

HLS2: A new plugin variable will be added for storage format preference.
  - Name: --caching_sha2_password_storage_format
  - Type: Global, Dynamic
  - Accepted Values: CRYPT5, PBKDF2_SHA512
  - Default: CRYPT5

HLS3: caching_sha2_password_generate API of caching_sha2_password will be 
modified to check storage format for password transformation. This will allow 
CREATE | ALTER USER to use the latest storage format preference.

HLS4: Serialized string used for PBKDF2 will have following characteristics
  - digest_type identifier: B
  - iteration: 3 digit hex * 1000
  - salt: CRYPT_SALT_LENGTH
  - digest: In base64 format
E.g. serialised string for password "HahaH0hO1234#$@#%" with salt 
"01234567899876543210"
$B$00a$01234567899876543210$6a3658ef7ba465c688954334730e6836806513b0219dc45d1eaf
ad9d88021959ba0b9171caa5869f41242b95d303aee5c9d65144221069ba5ee03f595e8feeda

HLS5: Password verification (Either at the time of authentication or during 
password store load), will rely on stored transformation for verification 
regardless of the preference set by variable described in HLS1.

HLS6: Replication consideration:
HLS6.1: There is no change in propagating CREATE | 
ALTER USER changes to secondaries/replicas. Due to additional storage format 
support, whichever format is used to generate hash on primary for a given user 
account, same format will be replicated across all secondaries/replicas.
HLS6.2: The assumption is that secondaries and replicas are upgraded before 
primary. This is typically required for any new feature to work seamlessly.
HLS6.3: Care must be taken by the end user to make sure that --
caching_sha2_password_enforce_storage_format is set to same value on all nodes 
to avoid different behaviour.

HLS7: A new plugin variable will be added to enforce storage format specified by 
option mentioned in HLS2
  - Name: --caching_sha2_password_enforce_storage_format
  - Type: Global, Dynamic
  - Accepted Values: 1(TRUE), 0(FALSE)
  - Default: 0
HLS7.1: If variable value is set to FALSE, user accounts with other storage 
format will continue to function as usual. Their password format will be changed 
as a part of next password change.
HLS7.2: When variable value is set (either true or false) at runtime, cache 
for fast authentication will be cleared.
HLS7.3: If variable value is set to TRUE, when user tries to login using 
password that's stored using the format other than the one set by --
caching_sha2_password_storage_format, such a user will be forced to change the 
password upon logging. Further, the password will not be cached internally to 
facilitate fast logging.
HLS7.4: In case of dual password, the format of the password used by user will 
be used for checks mentioned in HLS7.3 - not both.


HLS8: Authentication plugin ABI will be amended to support a new return code 
CR_OK_FORCE_PASSWORD_CHANGE. When set, connection's password expired attributed 
will be marked to TRUE in Security context - forcing user to change the password 
immediately after login.

HLS9: caching_sha2_password plugin's authentication method will be amended to 
return CR_OK_FORCE_PASSWORD_CHANGE iff:
- --caching_sha2_password_enforce_storage_format is set to 1(TRUE)
- The account is using storage format other than the one specified by --
caching_sha2_password_storage_format.

HLS10: Variable --caching_sha2_password_digest_rounds will be made dynamic to be 
consistent with other two options related to how password storage format is 
configured.

HLS11: X plugin authentication will be amended to support verifying password 
stored in PBKDF2 format.