Core: treat gRPC ResourceExhausted 'message larger than max' as non-r…

[mnnekrashevich]

Core: treat gRPC ResourceExhausted "message larger than max" as non-retryable

Fixes #621

Problem

When sending a large payload (e.g. UPSERT with a $data parameter exceeding the gRPC message limit),
the driver returns ResourceExhausted ("trying to send message larger than max"). This error is
currently classified as retryable, so the SDK retries it with slow backoff up to maxRetries times.
Since the payload size does not change between attempts, every retry fails identically — the operation
effectively hangs until timeout or context cancellation, instead of failing fast.

Root cause

RESOURCE_EXHAUSTED is unconditionally mapped to StatusCode.CLIENT_RESOURCE_EXHAUSTED in
GrpcStatuses.getStatusCode(). That status is in RETRYABLE_STATUSES and mapped to slow backoff in
YdbRetryConfig and both SessionRetryContext implementations, so the retry loop never distinguishes
the deterministic "message too large" case from transient server-side resource exhaustion.

Fix

In GrpcStatuses.getStatusCode(), inspect the gRPC status description when the code is
RESOURCE_EXHAUSTED and map the message-size-limit variants to BAD_REQUEST (non-retryable),
mirroring the fix already merged in the Go SDK (ydb-platform/ydb-go-sdk#2105):

• "trying to send message larger than max" (client-side send)
• "received message larger than max" (client-side receive)

All other ResourceExhausted errors (quota, rate limiting) keep the existing behavior and remain retryable.

Tests

Added to GrpcStatusesTest: send/receive variants map to BAD_REQUEST, other descriptions keep
CLIENT_RESOURCE_EXHAUSTED. Verified with ./mvnw test (all modules, BUILD SUCCESS).