Implement logic to validate dbms set at changeset and stored procedure levels

[MalloD12]

Impact

• Bug fix (non-breaking change which fixes expected existing functionality)
• Enhancement/New feature (adds functionality without impacting existing logic)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

Implement validateDefinitions() methods to validate single or a list of dbms attribute values set for a given changeset or store procedure.

Fixes #1795

Things to be aware of

• Validation logic basically relies on looking for a database a given definition (dbms).

Things to worry about

• Nothing

Additional Context

• Nothing

[github-actions]

Unit Test Results

  4 644 files  ±    0    4 644 suites  ±0   34m 34s ⏱️ - 1m 51s
  4 636 tests +  10    4 417 ✔️ +  10     219 💤 ±0  0 ❌ ±0 
54 804 runs  +120  49 780 ✔️ +120  5 024 💤 ±0  0 ❌ ±0 

Results for commit cefd673. ± Comparison against base commit 165c594.

♻️ This comment has been updated with latest results.

[nvoxland]

Code review and test results:

Things to be aware of:

• Changes make sense to me
• Can see it catching mistyped dbms attributes in integration tests

Things to worry about:

• Nothing

[XDelphiGrl]

This fix allows Liquibase to validate that the DBMS values provided at the changeset level contain valid database platform shortnames. If a changeset has an unrecognized value in the DBMS attribute, by default, Liquibase will throw a validation error. The DBMS attribute can have one or many comma-separated database shortnames.

• New tests added for one and many DBMS values.
• New test added for createProcedure with DBMS values.
• New test added for DBMS keywords "all" and "none."
• No additional testing required.

APPROVED