kv: consolidate RangeInfos in RPC responses

The kvclient can request information from the server about the
descriptor and lease of the range evaluating a request. This is
requested by setting a bit on the batch's header. The server was then
replying with information in every single request's header (as opposed
to the BatchResponse's header). For all the requests that hadn't been
split by the DistSender, the responses were the same.

This patch moves the responses to the BatchResponse's header - so, for
one RPC, there's gonna be exactly one response although the DistSender
will combine multiple of them. For backwards compatibility with 20.1,
new servers still populate the old location, and new clients copy from
the old location to the new one (subject to a cluster version gate).

The patch also removes the latching of a range's descriptor and lease
keys when requests will return range information. The latching was not
necessary - the respective keys are not actually read from the database
(in-memory caches are used) and clients don't care about any particular
consistency guarantees. In order to do away with this latching cleanly,
the server-side code that populates the range info is lifted from the
lower levels of request evaluation to a high-level.

This patch is motivated by upcoming changes which will make returning
range info more common. As such, both the latching and the duplication
of returned data become problems.

Release note: None

docs/generated/settings/settings.html

@@ -72,6 +72,6 @@
 <tr><td><code>trace.debug.enable</code></td><td>boolean</td><td><code>false</code></td><td>if set, traces for recent requests can be seen in the /debug page</td></tr>
 <tr><td><code>trace.lightstep.token</code></td><td>string</td><td><code></code></td><td>if set, traces go to Lightstep using this token</td></tr>
 <tr><td><code>trace.zipkin.collector</code></td><td>string</td><td><code></code></td><td>if set, traces go to the given Zipkin instance (example: '127.0.0.1:9411'); ignored if trace.lightstep.token is set</td></tr>
-<tr><td><code>version</code></td><td>custom validation</td><td><code>20.1-9</code></td><td>set the active cluster version in the format '<major>.<minor>'</td></tr>
+<tr><td><code>version</code></td><td>custom validation</td><td><code>20.1-10</code></td><td>set the active cluster version in the format '<major>.<minor>'</td></tr>
 </tbody>
 </table>

pkg/clusterversion/cockroach_versions.go

@@ -69,6 +69,7 @@ const (
 	VersionAddScheduledJobsTable
 	VersionUserDefinedSchemas
 	VersionNoOriginFKIndexes
+	VersionClientRangeInfosOnBatchResponse
 
 	// Add new versions here (step one of two).
 )
@@ -524,6 +525,12 @@ var versionsSingleton = keyedVersions([]keyedVersion{
 		Key:     VersionNoOriginFKIndexes,
 		Version: roachpb.Version{Major: 20, Minor: 1, Unstable: 9},
 	},
+	{
+		// VersionClientRangeInfosOnBatchResponse moves the response RangeInfos from
+		// individual response headers to the batch header.
+		Key:     VersionClientRangeInfosOnBatchResponse,
+		Version: roachpb.Version{Major: 20, Minor: 1, Unstable: 10},
+	},
 
 	// Add new versions here (step two of two).