BigTable: don't collapse the gRPC channel pool to a single channel

[adutra]

Problem

BigTableClientsFactory.createDataClient() built its channel-pool settings by starting from
ChannelPoolSettings.builder() — gax's generic defaults — and overriding only the properties that
had been explicitly configured. Those generic defaults are:

initial=1 min=1 max=200 minRpcs=0 maxRpcs=MAX_VALUE preemptiveRefresh=false

ChannelPoolSettings.isStaticSize() returns true when
minRpcsPerChannel == 0 && maxRpcsPerChannel == Integer.MAX_VALUE, and for a statically sized pool
ChannelPool never schedules its resize task at all:

if (!settings.isStaticSize()) {
  resizeFuture = ... scheduleAtFixedRate(this::resizeSafely, RESIZE_INTERVAL, ...);
}

So with nothing configured, every Nessie instance ran one gRPC channel to BigTable, permanently,
and maxChannelCount = 200 was dead configuration. Since gRPC starts queuing requests locally
beyond 100 concurrent RPCs per channel, this silently capped BigTable throughput per instance. Under
a burst the queued RPCs consume the request's total timeout and the call fails with
DEADLINE_EXCEEDED, reported as a small residual deadline on the final gax attempt (a clamped
remainder, not a configured timeout — see ExponentialRetryAlgorithm.createNextAttempt).

This also meant each instance held exactly one connection, hence one Google frontend, which makes
"all failing calls resolve to the same frontend IP" an expected consequence rather than a signal.

Change

Derive the pool settings from whatever the BigTable client library has already tuned for the
settings flavour in use, overriding only what is explicitly configured. Verified against
google-cloud-bigtable 2.60.0:

	initial	min	max	minRpcs	maxRpcs	preemptiveRefresh
BigTable library defaults	10	1	200	1	50	true
gax bare defaults (before)	1	1	200	0	MAX_VALUE	false

BigtableDataSettings.newBuilder() installs a dynamically sized pool; newBuilderForEmulator()
deliberately installs ChannelPoolSettings.staticallySized(1). Inheriting preserves the intent of
both, where deriving from gax's builder discarded both.

Two notes for reviewers:

• The hardcoded .setPreemptiveRefreshEnabled(true) is dropped in favour of inheriting it. For the
  real client path this is a no-op (the library default is already true); for the emulator it now
  correctly stays false, consistent with the emulator's setRefreshingChannel(false). This is
  separable from the rest of the change if you would rather keep the explicit call.
• channelPoolSettings(...) is extracted as a package-private static method so the behaviour can be
  unit-tested without constructing a client.

The Helm chart gains a bigtable.channelPool block, so these no longer have to be set through
advancedConfig.

Threat model

This change alters only client-side connection concurrency to BigTable.

The one security-adjacent dimension is resource consumption: instances will now open more
connections to BigTable than before (10 initially rather than 1, growing under load). This is the
BigTable client library's own default and is bounded by max-channel-count, and it reduces rather
than increases the availability risk the previous behavior created — the old single-channel cap was
itself a self-inflicted denial-of-service under load. Operators who need the old shape can pin
initial-channel-count=1 and max-channel-count=1, as noted in the changelog upgrade notes.

[snazy]

Inheriting Bigtable’s initial channel count changes the validity of partial existing configurations. For example, max-channel-count=1 used to yield initial=1,max=1; it now yields initial=10,max=1, and ChannelPoolSettings.build() rejects that range. Could we preserve a valid initial value when a configured min/max excludes the inherited one, and add coverage for partial bounds overrides?

Minor follow-up: the new Javadocs say setting minChannelCount equal to itself creates a static pool, and say leaving both RPC thresholds unset does so too. Both statements are incorrect after this change; the relevant equality is min versus max, and unset thresholds inherit Bigtable’s dynamic defaults. I would fix that in the same PR.