Add ability to specify custom schema for verification in postgres

[esune]

Added the ability to specify a custom schema name for backup verification in postgres when using the configuration file spec.
Following the convention used for JDBC, the schema can be specified by adding ?verifySchema=my_schema to the database spec.

This was developed as a set of postgres-specific overrides since other supported database providers do not have the concept of schema and it was simpler to customize one instance of the function to grab the database name from the connection spec rather than handling the different scenarios in the same function, but it can be refactored if necessary.

One thing this pattern could also be used for in the future is to specify the auth database for mongodb in the spec rather than using an environment variable like it is currently set-up to do.

Opening in draft mode while testing.

[WadeBarnes]

Looking good so far. A few comments and recommendations ...

The TABLE_SCHEMA variable has been used to this point to define the schema for verification. It's used by backup.mariadb.plugin and backup.postgres.plugin. The downside - It's global, hance this PR.

I think the TABLE_SCHEMA variable should be deprecated in favor of this new approach, where the new approach would contextually override the value in TABLE_SCHEMA.

Being able to backup a specific schema is an interesting addition, but I'm not sure it should be the default. The way it has worked up to now is the backup is a full backup, and then the verification verifies the schema of interest. This way when you restore the database, you're restoring a snapshot of everything, not just a single schema.

I also see that the new schema configuration setting is not being used for verification, the verification process is still only using the TABLE_SCHEMA variable.

[esune]

Implementation was updated to support backupSchema and verifySchema parameters:

• if backupSchema is specified, only the matching schema will be backed-up, otherwise the default mode will be used to backup everything
• if verifySchema is specified, the specified schema name will be used for verification. Code falls-back to use TABLE_SCHEMA if nothing is specified, which in turn falls back to verifying public if unset

Pondering whether to use backupSchema/verifySchema or just backup/verify as parameters: the first naming convention is explicit, but might be redundant given what the code is for?

More testing currently underway.

[WadeBarnes]

Pondering whether to use backupSchema/verifySchema or just backup/verify as parameters: the first naming convention is explicit, but might be redundant given what the code is for?

I personally prefer the explicit backupSchema/verifySchema.

[WadeBarnes]

LGTM pending the results of further testing.

[esune]

I tweaked the pg_dump command: unfortunately leaving a space between ${_schemaParam} and ${_database} would cause the command to fail when executed in a bash script - it would be successful when executed in the shell directly.

This results in successful backups, however I am getting errors with verification when executed manually for any of the backed-up databases (usually an error around the user already existing).

[esune]

See #132 (comment) for info about the verification failures. Leaving this PR as draft until I can understand more about how to fix the issue.

[esune]

Finally ready for review. I added code to post-process the roles dump and remove the default users (the user running the command as well as the postgres user) and verification is now successful. If any other users are in the roles dump, they will be retained.

Unfortunately it is not (easily) feasible to take old backups generated with versions 2.7.0->2.9.0 and do the same post-processing as they are verified/restored: I think a reasonable pattern would be to add documentation about the need to remove those lines from the backup before attempting a restore.

[esune]

Removed backupSchema for the time being as it seems to not be working reliably. verifySchema works as expected.

[WadeBarnes]

LGTM