Table GC: disable binary logging on best effort basis

[shlomi-noach]

Description

By way of optimization, our table lifecycle mechanism only purges rows on the primary tablet. It does so by disabling binary logging. Here's the explanation that is in the code:

	// Disable binary logging, re-enable afterwards
	// The idea is that DROP TABLE can be expensive, on the primary, if the table is not empty.
	// However, on replica the price is not as high. Therefore, we only purge the rows on the primary.
	// This saves a lot of load from the replication stream, avoiding excessive lags. It also
	// avoids excessive IO on the replicas.
	// (note that the user may skip the PURGE step if they want, but the step is on by default)

With this PR, we disable binary logging on best-effort basis. Here's the explanation that is in the PR's code:

	// However, disabling SQL_LOG_BIN requires SUPER privileges, and we don;t know that we have that.
	// e.g. on Amazon Aurora we do not have SUPER and can disable log bin.
	// We therefore disable log bin on best-effort base. Te logic is still fine and sound if binary logging
	// is left enabled. We just lose some optimization.

And so, running on e.g. Amazon Aurora, the lifecycle mechanism will not disable binary logging (it will try, but fail to, and silently proceed), and purge rows with binlogs enabled. Performance loss, but logic is sound.

Related Issue(s)

• Tracking issue, Tracking issue: safe, lazy, managed DROP TABLE #6689

Checklist

• Should this PR be backported?
• Tests were added or are not required
• Documentation was added or is not required

Impacted Areas in Vitess

Components that this PR will affect:

• Query Serving
• VReplication
• Cluster Management
• Build/CI
• VTAdmin

[deepthi]

Please fix the typo and then merge.

[aquarapid]

Sorry for getting in here late; but I did modify the transition state times locally ; and performed a manual end-to-end verification. All good!