## Environment

**Liquibase Version**: 4.4.1

**Liquibase Integration & Version**:

**Liquibase Extension(s) & Version**: liquibase-hibernate5 4.3.5

**Database Vendor & Version**: Postgresql 12

**Operating System Type & Version**: Ubuntu 20.04 LTS


## Description

See #1477 for a description of the problem, we have the same problem again (same symptoms), only the cause is slightly different. Once again the "bulk query/cached results" is broken.

The generate snapshot for postgres databases only finds a maximum of four unique constraints, meaning that if we diff with our jpa prebuild database we get a changelog that wants to add all other uniqueconstraints (even though they exist, the problem is in the snapshot generation).

The problem is that after four uniqueconstraints, the UniqueConstraintSnapshotGenerator switches to a bulk query, whose results get cached, and afterwards retrieves the results directly from the cache. Due to https://github.com/liquibase/liquibase/commit/95a3f221683ab81dac8445ec883d1f49311ab030 and https://github.com/liquibase/liquibase/commit/579f23d2253fdf41a85d58d523af9909624f5379 there is a cachekey mismatch between storing and retrieving for at least Postgresql, and possibly all non-MySQL databases: the Postgresql query does not contain a "table" column in the resultset, meaning that the cachekey contains `null` for the tablename upon storing, but upon retrieval the actual tablename is used, so no result is found in the cache and the UniqueConstraint does not get added to the snapshot.

## Steps To Reproduce

List the steps to reproduce the behavior.
Create a DatabaseSnapshot based on a fully initialized (ie, all changelog run) postgres database, create a DatabaseSnapshot for the exact same schema but based on a hibernate/jpa annotations "database" (or a fully initialized MySQL database, as long as it is guaranteed to include all uniqueconstraints). (Make sure both databases contain 5+ uniqueconstraints ).

Run a diff on the two snapshot using the liquibase DiffGenerator.

## Actual Behavior
The diff reports a difference in uniqueconstraints caused by the postgres database snapshot having fewer unique constraints than the other snapshot.

## Expected/Desired Behavior
Both databasesnapshots should have the same uniqueconstraints.

## Screenshots (if appropriate)
If applicable, add screenshots to help explain your problem.

## Additional Context
Add any other context about the problem here.

/**
     * To support bulk query, the resultSet must include a CONSTRAINT_CONTAINER column for caching purposes
     */
    protected boolean supportsBulkQuery(Database database) {
        return !(database instanceof DerbyDatabase)
                && !(database instanceof FirebirdDatabase)
                && !(database instanceof SybaseASADatabase)
                && !(database instanceof Ingres9Database)
                && !(database instanceof InformixDatabase);
    }
    /**
     * Gets an SQL query that returns the constraint names and columns for all UNIQUE constraints.
     *
     * @param database A database object of the InformixDatabase type
     * @param schema   Name of the schema to examine (or null for all)
     * @param name     Name of the constraint to examine (or null for all)
     * @return A lengthy SQL statement that fetches the constraint names and columns
     */
    private String getUniqueConstraintsSqlInformix(InformixDatabase database, Schema schema, String name) {
        StringBuilder sqlBuf = new StringBuilder();
        sqlBuf.append("SELECT * FROM (\n");
        
        
        for (int i = 1; i <= 16; i++) {
            if (i > 1)
                sqlBuf.append("UNION ALL\n");
            sqlBuf.append(
                    String.format("  SELECT\n" +
                                    "    CONS.owner,\n" +
                                    "    CONS.constrname AS constraint_name,\n" +