VTGate's foreign key operations should ignore vitess-internal tables

[shlomi-noach]

Work of VTGate foreign key support described in #12967, and some substantial work in #13823.

Vitess maintains internal tables of the following forms:

• GC tables, e.g. _vt_HOLD_...
• Online DDL tables, e.g. _..._vrepl tables

Those tables can be identified by IsInternalOperationTableName(), as defined here:

vitess/go/vt/schema/name.go

Lines 58 to 71 in 99271d4

	// IsInternalOperationTableName answers 'true' when the given table name stands for an internal Vitess
	// table used for operations such as:
	// - Online DDL (gh-ost, pt-online-schema-change)
	// - Table GC (renamed before drop)
	// Apps such as VStreamer may choose to ignore such tables.
	func IsInternalOperationTableName(tableName string) bool {
	if IsGCTableName(tableName) {
	return true
	}
	if IsOnlineDDLTableName(tableName) {
	return true
	}
	return false
	}

Reasoning is that these tables are non-production, and are likely to be out of sync with parent/child relationships.

• A *_vrepl table is either ongoing an Online DDL operation via vreplication, which means it's being slowly and asynchronously populated from another table, or is the "leftover" of the original table once cut-over is complete. In both cases the table cannot be guaranteed to agree to FK constraints. In fact, it is harmful for VTGate to work with these queries because these are being populated by vreplication.
• A _vt_DROP... table is for example one that's about to be dropped. It does not make sense to withhold operations in production table due to e.g. missing rows in this table.

VTGate should completely ignore any parent-child relationship where either parent or child (or both) have an internal table name.

[harshit-gangal]

The best is to avoid sending any information from the vttablet to vtgate about those table that they exists. We would not need any logic in VTGate for it.

[shlomi-noach]

@harshit-gangal does that mean one would never be able to e.g. SELECT COUNT(*) FROM _..._vrepl? I'm not opposed, just trying to understand the impact.

How would we go about not sending information from vttable about those tables?

[harshit-gangal]

For unsharded you can, for sharded you cannot because we do not know the sharding key. Nothing to lose here.

[shlomi-noach]

Solution proposed in #13897