Add RedisTimeSeries (TS.*) support

[HwangRock]

Implements the CRUD portion of the RedisTimeSeries umbrella #2716.

Motivation

Lettuce has no RedisTimeSeries support; docs/compatibility-roadmap.md lists it as "Not Supported". Jedis, redis-py, node-redis, and go-redis all ship it. This adds the create/read/update/delete surface so the module is usable from Lettuce.

Modification

13 commands across the sync, async, reactive, cluster, and coroutine APIs:

TS.CREATE  TS.ALTER  TS.CREATERULE  TS.DELETERULE  TS.DEL
TS.ADD     TS.MADD   TS.INCRBY      TS.DECRBY
TS.GET     TS.MGET   TS.INFO        TS.QUERYINDEX

Structure mirrors the existing Bloom/Cuckoo Filter modules:

• RedisTimeSeriesCommandBuilder (package-private) for RESP encoding.
• A template interface (src/main/templates/.../RedisTimeSeriesCommands.java) that the apigenerator turns into the sync/async/reactive and node-selection variants.
• Argument builders under io.lettuce.core.timeseries.arguments.
• Value/parser types under io.lettuce.core.timeseries (TsSample, TsInfoValue, TsMGetValue).

Two things worth calling out for review:

• RESP2/RESP3 parsing. TS.INFO and TS.MGET return different container shapes across protocols, and the labels field is a nested pair-array under RESP2 but a map under RESP3. The parsers branch on the actual reply type (ComplexData.isMap()), not the negotiated protocol version — the server falls back to arrays on older module APIs even under RESP3, so keying off the protocol version would misparse.
• TS.INCRBY/TS.DECRBY share one args class (TsIncrByArgs) because the server registers both to the same handler (TSDB_incrby), differing only by an argv[0] compare. They intentionally expose duplicatePolicy() but not onDuplicate(), since the server hardcodes DP_LAST on that path.

Read-only commands (TS.GET/TS.MGET/TS.INFO/TS.QUERYINDEX) are registered in ReadOnlyCommands for replica routing.

Range queries (TS.RANGE/TS.REVRANGE/TS.MRANGE/TS.MREVRANGE, #2708–#2711) are left for a follow-up PR. Their GROUPBY/aggregation responses have RESP2/RESP3 shapes that are not documented and need separate handling, so I kept them out to keep this reviewable.

Result

Verified against redis:8. Tests included:

• Unit tests for the builder, each args class, and the parsers (including RESP2/RESP3 branch coverage).
• Integration tests for CRUD round-trips.
• Edge-case integration tests: duplicate-policy behaviour (all six policies), IGNORE filters, NaN/Infinity values, compaction timing, and label charset limits — each assertion pinned to observed server behaviour.

Two known gaps:

• One reactive integration test is @Disabled pending Signal onError instead of hanging when a reactive complex-output command errors #3851. That PR fixes a pre-existing hang in RedisPublisher (unrelated to this change) where reactive commands don't terminate on a server error. sync/async are unaffected and tested here.
• The cluster integration test compiles but couldn't run locally (the client-libs-test image has no arm64 manifest); it needs CI or an x86 host.

Issues

Resolves #2699
Resolves #2700
Resolves #2701
Resolves #2702
Resolves #2703
Resolves #2704
Resolves #2705
Resolves #2706
Resolves #2707
Resolves #2712
Resolves #2713
Resolves #2714
Resolves #2715

Part of #2716. #2708, #2709, #2710, #2711 remain for the range-query follow-up.

I can split this differently or adjust the API if the direction looks off.

---

Note

Medium Risk
Large additive API surface with non-trivial RESP2/RESP3 parsing; mistakes would misdecode TS.INFO/TS.MGET rather than affecting core Redis commands, but cluster/replica routing depends on correct read-only classification.

Overview
Adds first-class RedisTimeSeries support to Lettuce (create/alter/rules, add/madd/incr/decr, get/mget/info/queryindex), wired through the same module pattern as Bloom/Cuckoo/TopK: RedisTimeSeriesCommandBuilder, apigenerator-driven APIs, and io.lettuce.core.timeseries types/argument builders.

AbstractRedisAsyncCommands / AbstractRedisReactiveCommands now implement RedisTimeSeries*Commands and delegate ts* methods to the new builder. Cluster node-selection interfaces and Kotlin coroutine facades are extended the same way. Protocol layer gains TS_* command types, TimeSeries CommandKeywords, and read-only registration for replica routing.

Response parsing for TS.INFO and TS.MGET branches on actual reply shape (ComplexData.isMap()), not negotiated RESP version, so nested RESP2 label arrays and RESP3 maps both decode correctly. TsIncrByArgs is shared by TS.INCRBY/TS.DECRBY (no onDuplicate). Range commands (TS.RANGE / MRANGE etc.) are explicitly out of scope for this PR.

^{Reviewed by Cursor Bugbot for commit e745b62. Bugbot is set up for automated code reviews on this repo. Configure here.}

[a-TODO-rov]

Hey @HwangRock
Thanks for this big contribution 😅
I guess it will be some long review ahead.

[HwangRock]

@a-TODO-rov Thanks! 😄 Yeah, it ended up being a pretty big PR. I tried to keep it as one coherent slice covering the CRUD commands, while leaving the range queries (TS.RANGE/MRANGE, etc.) for a separate PR to keep this one focused.

If you'd still prefer smaller chunks, I'd be happy to split the CRUD commands further (for example, lifecycle / writes / reads). Just let me know what would make the review easier.