Liquibase Integration & Version: CLI, Maven

Liquibase Version: 4.3.5

Database Vendor & Version: PostgreSQL

Operating System Type & Version: Linux, Windows.

## Description
When a customer used Liquibase 3.5.3 with a yaml **PostgreSQL** create table change type containing a column with a data type "SERIAL" the generated SQL still retained the same data type.  However, when upgraded to 4.3.5 the data type changed to "INTEGER GENERATED BY DEFAULT AS IDENTITY".

## Background
This is "as designed" because we handle serial as meaning "auto-increment integer" and for postgresql, we implement auto-increment integers using the suggested/standard GENEREATED BY DEFAULT AS IDENTITY.

It's a change vs. the behavior in 3.x, but if we reverted that change, it will be an equal change in behavior for everyone using 4.0+. 

BUT: there is a larger discussion we've been pushing off on how much and how little we "smooth" changelogs and this is one specific example of this. 

We shouldn't just break everyone using 4.0+ in order to change this behavior back to the 3.x version without first having that larger discussion and determining both how we want the overall functionality to work and how to preserve backwards compatibility. Otherwise we just keep jerking users around.

The longer discussion text has been moved to a comment below.

## Decided Fix For This Issue
There is the liquibase.convertDataTypes setting we currently use for preserving clob/text types and timestamp types which will be used for this as a targeted solution to this. 

## Steps To Reproduce
1. Use the Liquibase version 3.5.3
1. Create the following changeset:

```java
databaseChangeLog:

    # Create Table featr
    - changeSet:
        id: reference-create-table-featr
        author: rmg
        changes:
        - createTable:
            remarks: "Captures information regarding application features."
            tableName: featr
            schemaName: reference
            columns:
            - column:
                name: featr_uid
                remarks: "The value assigned to uniquely identify a row in this table."
                type: SERIAL
                constraints:
                    nullable: false
            - column:
                name: featr_nm
                remarks: "Name of the feature."
                type: java.sql.Types.VARCHAR(100)
                constraints:
                    nullable: false
```

1. Run `liquibase updateSQL`
1. Upgrade Liquibase to version 4.3.5
1. Run `liquibase updateSQL`

## Actual Behavior
In step #4 here is the following output for the generated updateSQL command with Liquibase version 3.5.3:

```sql
-- Changeset changeset-example.yaml::reference-create-table-featr::rmg
CREATE TABLE reference.featr (featr_uid SERIAL NOT NULL, featr_nm VARCHAR(100) NOT NULL, featr_desc VARCHAR(500) NOT NULL, app_sctn_cd VARCHAR(4), featr_ovrd_ind VARCHAR(1), dactvn_rsn_txt VARCHAR(500), eff_stdt date DEFAULT NOW() NOT NULL, eff_endt date, insrt_ts TIMESTAMP WITHOUT TIME ZONE DEFAULT NOW() NOT NULL, insrt_pin VARCHAR(6) NOT NULL, lu_ts TIMESTAMP WITHOUT TIME ZONE DEFAULT NOW() NOT NULL, lu_pin VARCHAR(6) NOT NULL);
```

In step #6 here is the following output for the generated updateSQL command with Liquibase version 4.3.5:

```sql
CREATE TABLE reference.featr (featr_uid INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL, featr_nm VARCHAR(100) NOT NULL, featr_desc VARCHAR(500) NOT NULL, app_sctn_cd VARCHAR(4), featr_ovrd_ind VARCHAR(1), dactvn_rsn_txt VARCHAR(500), eff_stdt date DEFAULT NOW() NOT NULL, eff_endt date, insrt_ts TIMESTAMP WITHOUT TIME ZONE DEFAULT NOW() NOT NULL, insrt_pin VARCHAR(6) NOT NULL, lu_ts TIMESTAMP WITHOUT TIME ZONE DEFAULT NOW() NOT NULL, lu_pin VARCHAR(6) NOT NULL);
```

## Expected Behavior
The output from Liquibase version 4.3.5 should have been as version 3.5.3
The data type should be **SERIAL**.

## Test Cases
* With liquibase.convertDataTypes=false, SMALLSERIAL, SERIAL and BIGSERIAL columns in createTable are created as SMALLSERIAL/SERIAL/BIGSERIAL respectively.
* With liquibase.convertDataTypes=true (or not set), SMALLSERIAL, SERIAL and BIGSERIAL columns in createTable continue to be created as GENERATED BY DEFAULT AS IDENTITY
* NO TEST: addColumn cannot add serial columns, so no code changes there
* No changes or regressions in snapshot or diff logic

## Test Automation Requirements
* Add a changetype test to [https://github.com/liquibase/liquibase-test-harness](https://github.com/liquibase/liquibase-test-harness|smart-link) 
  * Follow all naming and project structure conventions described in the README
  * Write your test on a branch named LB-1729
  * The test should create two tables with three columns, one for SMALLSERIAL, SERIAL, BIGSERIAL
  * One createTable changeset should have convertDataTypes=false
  * One createTable changeset should have convertDataTypes=true
  * Manually generate the SQL for test validation (this is the expectedSql in the test harness)
  * Manually generate a snapshot for the test to validate against (this is the expectedSnapshot in the test harness)
  * Verify the test passes with the fix
  * Submit a PR and request at least two reviewers (ask [~accountid:557058:7570b03f-9e8f-43d9-8b35-d5c4b709ac8b] for guidance on who is the best for a PR review).



┆Issue is synchronized with this [Jira Bug](https://datical.atlassian.net/browse/LB-1729) by [Unito](https://www.unito.io)
┆Fix Versions: Community 4.x

/*
         * Here, the list of columns and constraints in the form
         * ( column1, ..., columnN, constraint1, ..., constraintN,
         * ends. We cannot leave an expression like ", )", so we remove the last comma.
         */
        String sql = buffer.toString().replaceFirst(",\\s*$", "") + ")";
        if ((database instanceof MySQLDatabase) && (mysqlTableOptionStartWith != null)) {
            Scope.getCurrentScope().getLog(getClass()).info("[MySQL] Using last startWith statement ("+mysqlTableOptionStartWith.toString()+") as table option.");
            sql += " " + ((MySQLDatabase) database).getTableOptionAutoIncrementStartWithClause(mysqlTableOptionStartWith);
        }
        if ((statement.getTablespace() != null) && database.supportsTablespaces()) {
            if ((database instanceof MSSQLDatabase) || (database instanceof SybaseASADatabase)) {
                sql += " ON " + statement.getTablespace();
            } else if ((database instanceof AbstractDb2Database) || (database instanceof InformixDatabase)) {
                sql += " IN " + statement.getTablespace();
            } else {
                sql += " TABLESPACE " + statement.getTablespace();
            }
        }
        if ((database instanceof MySQLDatabase) && (statement.getRemarks() != null)) {
            sql += " COMMENT='" + database.escapeStringForDatabase(statement.getRemarks()) + "' ";
        }
        additionalSql.add(0, new UnparsedSql(sql, getAffectedTable(statement)));
        return additionalSql.toArray(new Sql[additionalSql.size()]);
    }
    protected Relation getAffectedTable(CreateTableStatement statement) {
        return new Table().setName(statement.getTableName()).setSchema(new Schema(statement.getCatalogName(), statement.getSchemaName()));
    }
}