[Task] Ruby: Add AZ_AFFINITY_ALL_NODES read strategy

[xShinnRyuu]

Description

GLIDE added a new read strategy, AZAffinityAllNodes, in valkey-io/valkey-glide#6721, which closed valkey-io/valkey-glide#6653. Only the Python binding was wired up, so every other client needs the same surface. This issue tracks the Ruby side.

The strategy spreads read requests equally, in round robin, across all nodes in the client's Availability Zone, primary and replicas alike. When no node in the client's AZ is available it falls back to a round robin across all nodes. It differs from AZ_AFFINITY_REPLICAS_AND_PRIMARY in that it does not prioritise replicas ahead of the primary, which is what makes an even per-node read distribution possible on ElastiCache deployments that hit the 5 replica cap. The motivation is written up in valkey-io/valkey-glide#6653.

Prerequisite

The vendored native library has to be built from a GLIDE revision that includes AZAffinityAllNodes = 6 in glide-core/src/protobuf/connection_request.proto, which landed with valkey-io/valkey-glide#6721. Valkey::ReadFrom values are forwarded to the core as raw strings, so until the vendored core knows the value the constant cannot work.

Checklist

• Add AZ_AFFINITY_ALL_NODES = "AZAffinityAllNodes" to Valkey::ReadFrom in lib/valkey/read_from.rb.
• Add the matching when arm to the client_az validation in lib/valkey.rb, so a missing client_az raises the same way it does for the two existing AZ strategies. Without it the new strategy would silently accept a nil AZ.
• Extend any read-only mode incompatibility handling to cover the new strategy.
• Add coverage in test/valkey/connection_config_test.rb, which already exercises the existing read-from values and their AZ validation.
• Update test/lint/connection_options.rb if it enumerates the accepted read_from: values.

Additional Notes

The Python diff in valkey-io/valkey-glide#6721 is a close reference for the binding surface, including the exact wording of the validation errors.

lib/valkey/read_from.rb carries a helpful note about LowestLatency being a valid GLIDE value that is deliberately not exposed as a constant because it panics in the vendored native library. The new strategy is not in that category: it is fully implemented in the core, so it can be exposed normally once the vendored library is current.

The same parity gap in the other clients:

• Java [Task] Java: Add AZ_AFFINITY_ALL_NODES read strategy valkey-glide#6790
• Node [Task] Node: Add AZAffinityAllNodes read strategy valkey-glide#6791
• Go [Task] Go: Add AzAffinityAllNodes read strategy valkey-glide#6792
• C# [Task] CSharp: Add AzAffinityAllNodes read strategy valkey-glide-csharp#533
• PHP [Task] PHP: Add READ_FROM_AZ_AFFINITY_ALL_NODES read strategy valkey-glide-php#316