chore: set up DB import/export scripts

[dustin-jw]

Description

This sets up import and export scripts for syncing DBs across environments. Some key benefits of this approach:

• Files are always gzipped to keep size down when transferring to other devs/environments
• Naming is flexible so you don't need to rename files before importing/sending to other devs
• Backups are automatically saved when you import a DB, allowing you to revert back if needed
• Exported/backed up files are timestamped and can be named, allowing for better organization

Closes #32

Validation DB

You can use this DB export to verify the import functionality.

db-export-2023-09-22T17-48-43_UTC.sql.gz

To Validate

1. Pull down this branch
2. Add SITE_URL=https:\\/\\/example.com to your .env file (this is used to replace absolute URLs based on environment)
3. Run npm start
4. Run npm run backup-db to save your current DB (confirm that a file is added to sql/backups)
5. Run npm run backup-db named-backup to confirm that this uses the name you give it instead of db-backup-*
6. Download the provided DB export for testing and put it in your sql folder
7. Run npm run import-db, confirming that another backup is created before the import happens, and that the imported file is moved to sql/previous-imports when the script is finished running
8. Visit http://localhost:8000 and confirm that there's a post with the title "This test post is for data exports!"
9. Run npm run export-db, confirming that a gzipped sql file is added to sql/exports
10. Run npm run export-db named-export, confirming that the new export file uses the name you gave it instead of db-export-*
11. Move your original backup DB to the top-level sql folder and run npm run import-db to get your original DB back

[rise-erpelding]

This is great! It sure does make working with database imports and exports less of a headache--they can now be included easily on PRs, imported and exported super easily without having to rename files, and it is so fast for me to switch to a database vs. importing it as an .xml. Your documentation is also great! 🌟

[rise-erpelding]

Not related to this PR but I'm just realizing we don't have GOOGLE_API_KEY in here, should we?

[dustin-jw]

I'm a little more inclined to delete the reference to GOOGLE_API_KEY, since it isn't actually used for anything. It is useful as an example, though, so maybe we could make it clearer that it is just an example–otherwise I could see someone getting thrown off if they set an API key and nothing changed about the site. Maybe like this?

function define_theme_globals() {
	// phpcs:ignore
	define( 'CUSTOM_ENVIRONMENT_VARIABLE', $_SERVER['CUSTOM_ENVIRONMENT_VARIABLE'] ?? '' );
}
add_filter( 'init', 'define_theme_globals' );

I'll create an issue for it, and we can work out the details from there.