Decouple the term TxnScope from the Stale Read code

[JmPotato]

Enhancement

Since the two features, Stale Read and Local Txn were developed together, the former borrows many of the concepts from the latter. TxnScope should be a term referring to the Global/Local Transaction scopes specifically. However, in the code of Stale Read, TxnScope is also used widely to indicate the TiKV locality, which brings some confusion into the code readability.

tidb/distsql/request_builder.go

Lines 51 to 75 in ab30467

	// Build builds a "kv.Request".
	func (builder *RequestBuilder) Build() (*kv.Request, error) {
	if builder.ReadReplicaScope == "" {
	builder.ReadReplicaScope = kv.GlobalReplicaScope
	}
	if builder.ReplicaRead.IsClosestRead() && builder.ReadReplicaScope != kv.GlobalReplicaScope {
	builder.MatchStoreLabels = []*metapb.StoreLabel{
	{
	Key: placement.DCLabelKey,
	Value: builder.ReadReplicaScope,
	},
	}
	}
	failpoint.Inject("assertRequestBuilderReplicaOption", func(val failpoint.Value) {
	assertScope := val.(string)
	if builder.ReplicaRead.IsClosestRead() && assertScope != builder.ReadReplicaScope {
	panic("request builder get staleness option fail")
	}
	})
	err := builder.verifyTxnScope()
	if err != nil {
	builder.err = err
	}
	return &builder.Request, builder.err
	}

We should decouple the TxnScope from the Stale Read code to make it more clear when we try to write some code that is related to the locality of the TiKV store.

[JmPotato]

#30535 may fix this issue.