[WIP] sql: pass descs.Collection to InternalExecutor under planner context

[ZhouXing19]

WIP

Currently, when an internal executor is used inside a transaction
under a planner context, it always creates a new descriptor collection
rather than inheriting from the outer transaction.

We'd like to pass desc.Collection to an internal executor ONLY when
the internal executor is used under the planner context.
To do this, we

1. introduced a type extraTxnStateUnderPlanner, which is only accessible
   under the sql package;
2. deprecate ExecutorConfig.InternalExecutorFactory, and break the internal
   executor initialization into 2 steps:
   a. under newSQLServer(), we initialize an InternalExecutorProto, which
   cannot be used to execute queries;
   b. initialize the true internal executor with desc.Collection via
   extraTxnStateUnderPlanner, if it's under the planner context.

Fixes #69495

Release note: None

[cockroach-teamcity]

This change is 

[ajwerner]

This is neat. This change is very good for negating the efficiency problems we run into when we construct new internal executors for querying virtual tables, but it doesn't really mitigate issues like we saw in #76764. In order to have those work correctly we'd need to initialize and share also these parts of state:

cockroach/pkg/sql/conn_executor.go

Lines 1229 to 1240 in 928f605

	// jobs accumulates jobs staged for execution inside the transaction.
	// Staging happens when executing statements that are implemented with a
	// job. The jobs are staged via the function QueueJob in
	// pkg/sql/planner.go. The staged jobs are executed once the transaction
	// that staged them commits.
	jobs jobsCollection
	// schemaChangeJobRecords is a map of descriptor IDs to job Records.
	// Used in createOrUpdateSchemaChangeJob so we can check if a job has been
	// queued up for the given ID. The cache remains valid only for the current
	// transaction and it is cleared after the transaction is committed.
	schemaChangeJobRecords map[descpb.ID]*jobs.Record

In reality, I think sharing the descs.Collection for the purpose of writing is a bad idea. It's really good for when we're using the (*planner).QueryRowEx/QueryIteratorEx but I'm suspicious of it in other use cases. I'm worried that this new interface surface area may give folks a false sense of security that if they do inject a descs.Collection then they do can do anything with an internal executor.

My preference would be that we find a way to hide the surface area more, and that we disable all schema changes using an internal executor with an explicit transactions, and then we just do this coupling for the internal executors accessed via the planner interface used in the EvalContext.

Does that seem reasonable?

[ZhouXing19]

Note to myself:
Now we restrict the usage makeSessionBoundInternalExecutorFromProtoUnderPlanner to under sql package, which is good -- if an ie is used from any other packages to run queries, ie.extraTxnState cannot be set.

The problem unsolved is that if under a planner context, the ie can still be initialized with MakeSessionBoundedInternalExecutorFromProto, but they should ALWAYS be inited with makeSessionBoundInternalExecutorFromProtoUnderPlanner.

I.e. we want to make the usage of makeSessionBoundInternalExecutorFromProtoUnderPlanner and MakeSessionBoundedInternalExecutorFromProto more "separate" -- if under a planner context, only makeSessionBoundInternalExecutorFromProtoUnderPlanner is allowed; otherwise, only MakeSessionBoundedInternalExecutorFromProto is allowed.