support embedded schema for cassandra and sql update-schema

[carlydf]

What changed?

This change adds a flag to temporal-sql-tool and temporal-cassandra-tool's update-schema and setup-schema to specify an embedded schema instead of a path to the schema directory or schema file.

NAME:
   temporal-cassandra-tool update-schema - update cassandra schema to a specific version

USAGE:
   temporal-cassandra-tool update-schema [command options] [arguments...]

OPTIONS:
   --version value, -v value      target version for the schema update, defaults to latest
   --schema-dir value, -d value   path to directory containing versioned schema
   --schema-name value, -s value  name of embedded versioned schema, one of: [cassandra/temporal cassandra/visibility]

NAME:
   temporal-sql-tool update-schema - update sql schema to a specific version

USAGE:
   temporal-sql-tool update-schema [command options] [arguments...]

OPTIONS:
   --version value, -v value      target version for the schema update, defaults to latest
   --schema-dir value, -d value   path to directory containing versioned schema
   --schema-name value, -s value  name of embedded versioned schema, one of: [mysql/v57/temporal mysql/v57/visibility mysql/v8/temporal mysql/v8/visibility postgresql/v96/temporal postgresql/v96/visibility postgresql/v12/temporal postgresql/v12/visibility]

Why?

We want to embed the db schemas in the temporal-sql-tool and temporal-cassandra-tool with go:embed so that customers can simply specify which schema they want using a flag instead of having to copy the schema files to wherever they're running the db tool and passing the path to the schema.

#2059

How did you test it?

I wrote a new unit test for reading the embedded file system, and the efs==nil codepath of the changed functions are all tested by the existing unit tests. I also updated the unit test for config validation to reflect the new changes.

I tested this locally with a locally running Postgres. Since the more complex changes are in updatetask.go, which is shared by the sql and the cassandra tool, I think there is no need to also test with a real cassandra db. I also built the cassandra command line tool and confirmed that the flags behaved as expected.

Potential risks

Schema updates could fail. But the changes are pretty contained to the new -s flag which isn't used anywhere in production yet, so the risk is very low. The code for the -d flag remained basically the same.

Is hotfix candidate?

No

[CLAassistant]

All committers have signed the CLA.

[tdeebswihart]

Do the setup-schema commands need to be updated as well? Seems like they should be

[carlydf]

Do the setup-schema commands need to be updated as well? Seems like they should be

thanks for catching! i missed this cuz the schema path is not required for that command, and everywhere we use it we always first run setup-schema -v 0.0 followed by update-schema, but you're totally right, i will go add :)

[tdeebswihart]

Thanks for working with me on some of this cleanup even though it wasn't from your work in the first place. The tool will be in a much better state after this!