Cleanup whitespace and comments in SQL query text

[timvaillancourt]

Description

This PR cleans up SQL query text in several files where whitespace, line separation and the use of comments were inconsistent

The rules I followed were:

1. All queries include a /* gh-ost */ or /* gh-ost database.table */ comment
2. Single-tabs (/t) are used for indentation
3. Queries are defined as the variable query := using backticks
4. SQL begins on the line following query after a single tab
   • Example:

     query := `
             select /* gh-ost */
             ...`

   • Exception: simple var-only queries without a FROM, example: select /* gh-ost */ @@global.log_slave_updates
5. SQL is further indented when these terms are encountered:
   • FROM/INTO
   • SET/ON DUPLICATE KEY UPDATE
   • VALUES
   • WHERE
   • ( or ) SQL-block brackets, example: a sub-query
   • INNER JOIN
   • ON
   • CASE
6. No newline at end of query var / close backtick after last word

What this PR does NOT address is the inconsistency in capitalization in SQL. I would like to leave this to a vote from the community in an up-coming GitHub Discussion, and I will follow-up on this separately

In case this PR introduced Go code changes:

• contributed code is using same conventions as original code
• script/cibuild returns with no formatting errors, build errors or unit test errors.

[meiji163]

looks nice!

[shaohk]

@timvaillancourt Does the time zone set here need to be configured as this.migrationContext.ApplierTimeZone? I noticed that other sessions are using this.migrationContext.ApplierTimeZone for setting the time zone, but here it is set to +00:00. Should this be adjusted?

[timvaillancourt]

@shaohk good question, that sounds more correct than +00:00 🤔

Based on the soak testing this logic has seen I don't think this causes an integrity problem, however. I think that may be because binlog row events contain the values from that primary/master (including dates/times), so it probably doesn't matter what timezone the applier session uses here. I believe gh-ost is using the decoded binlog row event values only

Fewer "what if?" questions is a good thing though, so I would still welcome this change if it passes integration testing at GitHub