Add ThingsBoard latest-telemetry and attributes DAOs on IoTDB Table Mode

[PDGGK]

This is the second PR of the GSoC series (follows #110, the timeseries TimeseriesDao, now merged). It adds the latest-telemetry and attributes storage paths for running ThingsBoard on Apache IoTDB 2.x Table Mode.

What this adds

1. IoTDBTableLatestDao — the ThingsBoard TimeseriesLatestDao SPI on Table Mode.

• Reads are derived-latest over the existing telemetry table (ORDER BY time DESC LIMIT 1 for a single key; LAST_BY(col, time) + MAX(time) GROUP BY key for all keys), so the normal full-save path needs no separate latest table.
• Plus a minimal latest overlay (telemetry_latest) that captures the latest-only write/delete cases the single-table derived read cannot satisfy (e.g. the EntityView LATEST_AND_WS copy path calls saveLatest with no paired save()). findLatest/findAllLatest merge the derived latest with the overlay by max timestamp per key (overlay wins an exact-ts tie). The overlay table is created only under the latest selector.
• removeLatest snapshots the derived and overlay latest separately under a per-identity lock and deletes the overlay row only when the overlay row's own timestamp is inside the half-open delete window — so an out-of-window overlay value is never wiped by a tag-only delete and survives as the next latest; the rewrite-resurrect path looks before the window across both telemetry and the overlay (max-ts-wins).
• The write-side max-ts guard and the remove snapshot read the derived/overlay latest B1-tolerantly (an ambiguous same-timestamp two-type row is treated as absent for the guard/snapshot, so it never blocks a saveLatest or removeLatest, and a subsequent overlay overwrite self-heals it); the strict read paths (findLatest/findAllLatest) still surface such a row as a fault.
• The key-discovery / batch SPI methods (findAllKeysByEntityIds(+Async), findLatestByEntityIds(+Async)) return an empty result rather than throwing — matching the official CassandraBaseTimeseriesLatestDao — because they back reachable endpoints (the dashboard "available telemetry keys" lookup, entity-delete housekeeping) where a throw would surface as an HTTP 500 / a failed cleanup task. Full derived implementations are Wk9 / Wk10.

2. IoTDBTableAttributesDao — the ThingsBoard AttributesDao SPI on Table Mode, against a dedicated entity_attributes table.

• Inert by default: activates only when database.attributes.type=iotdb-table is set — a selector that no current ThingsBoard release exposes — so a normal deployment never instantiates it and attributes keep flowing to the host entity DB. No @Repository; an AttributesDaoConflictGuard fails startup if a conflicting host AttributesDao is present; a constructor gate requires an explicit iotdb.attributes.cluster_mode acknowledgement.
• save is a failure-safe insert-then-delete-older (insert the current row at lastUpdateTs, then delete strictly-older rows for the identity), so an INSERT failure leaves the prior value intact; point reads use ORDER BY time DESC LIMIT 1. It returns a non-null version (the attribute's lastUpdateTs), which BaseAttributesService#doSave unboxes into AttributeKv(..., long).

Both follow the same activation isolation + compile-only ThingsBoard stub surface (excluded from the built jar) as #110, and reuse the module's single named session pool (deduped via @ConditionalOnMissingBean(name=...)); each DAO can be activated independently.

Testing

Verified with the build cache off: 153 unit tests + 37 Testcontainers integration tests (Latest 16 / Timeseries 9 / Attributes 12) against apache/iotdb:2.0.8-standalone; apache-rat, checkstyle, spotless, dependency-analyze, and enforcer all clean. The compile-only SPI stubs are pinned to the real ThingsBoard v4.3.1.2 signatures by StrategyFContractTest.

Points I'd appreciate review on

• Latest overlay shape. Because writes are async-batched, saveLatest cannot tell a latest-only write from a full-save's paired saveLatest, so telemetry_latest is a per-key latest store (one row per key), written on every saveLatest except when a strictly newer latest already exists (max-ts-wins; an exact-ts tie still overwrites, preserving the documented same-timestamp behaviour). The overlay write is a delete-then-insert so a same-timestamp two-type change resolves to a clean single-typed row. It is effectively a latest table (at most one extra overlay write per in-order latest update); I'd welcome confirmation the shape is acceptable, or a preference for a narrower variant.
• Documented Phase-1 residuals (in the IoTDBTableLatestDao javadoc): version is always null (IoTDB has no per-series sequence — same as the Cassandra backend); for a purely telemetry-derived (full-save) latest, removeLatest and a concurrent historical delete are separate futures, so a re-read can transiently disagree until the historical delete lands; telemetry_latest is TTL='INF' with no entity-level cleanup; a telemetry-only write (saveWithoutLatest / "skip latest persistence") surfaces via the derived read; and the per-identity overlay lock is in-JVM (Striped), so in a clustered deployment two nodes writing the same identity concurrently can transiently leave two overlay rows until the next write (the max-ts read merge still returns the newer value, and the B1-tolerant guard/remove reads prevent a two-type overlay row from wedging writes) — a symmetric cluster-mode acknowledgement for the latest overlay is a mentor-review option.
• AttributesDao.findAllKeysByDeviceProfileId with a non-null DeviceProfileId returns an empty list — matching the official non-relational backend (CassandraBaseTimeseriesLatestDao.findAllKeysByDeviceProfileId also returns Collections.emptyList()); the sole caller is a TENANT_ADMIN config-time UI key-enumeration endpoint (GET /api/deviceProfile/devices/keys/attributes) that tolerates empty. The rationale is documented in the DAO javadoc + README; a real device→profile lookup is a future optional enhancement.

Happy to iterate.

[PDGGK]

Thanks for the thorough review, @CritasWang — all five addressed in 511f9bf.

1. Duplicated bounded executor across the three DAOs (IoTDBTableLatestDao.java:816). Lifted the whole mechanism — initReadExecutor / submitReadTask / ReadTask / failDroppedReadTask and the shutdown-drain — into IoTDBTableBaseDao; the three DAOs now delegate, so a future shutdown-race fix lives in one place. Attributes' submitIoTask / IoTask / ioExecutor collapse onto the shared submitReadTask. The semantics you'd want preserved are unchanged: bounded ArrayBlockingQueue + AbortPolicy, per-DAO thread-name prefix, the IoTDBTableReadQueueFullException / IoTDBTableDaoShuttingDownException types, and the accepting=false → shutdownNow → drain ordering.

2. Duplicated small utilities (IoTDBTableLatestDao.java:806).sqlString (the single SQL single-quote escape point you flagged as the highest-risk to have scattered), kvEntry, requireTelemetryKey / requireKey, and entityPredicate are now single copies in the base and inherited by the DAOs.

3. Attributes executor borrowed iotdb.ts.read.* (IoTDBTableAttributesDao.java:251). Added a dedicated iotdb.attributes.executor.threads / .queue-capacity block (defaults identical to iotdb.ts.read, so no behavior change unless tuned); the attributes DAO now sizes from it, so its concurrency / backpressure can be tuned independently of the timeseries selector.

4. Write path shares the read executor + "read"-named queue-full exception (IoTDBTableLatestDao.java:298). I took the documentation path you offered rather than splitting the pools: a dedicated latest-overlay write executor would sit almost entirely idle (at most one small task per in-order latest update), so I kept the shared bounded executor and instead (a) enriched the IoTDBTableReadQueueFullException message to state explicitly that a saveLatest / removeLatest write burst can reject a concurrent findLatest / findAllLatest, and (b) documented the shared read+write executor/queue on saveLatest and on the base initReadExecutor. If you'd rather have the isolation, I'm happy to split it into separate read/write pools instead — just say the word.

5. Asymmetric cluster gate (IoTDBTableLatestDao.java:241). Added a symmetric iotdb.ts_latest.cluster_mode acknowledgement to the latest overlay, mirroring the attributes gate exactly (same accepted set {sticky-routing, disabled}, same fail-fast at construction), so the in-JVM Striped-lock cluster caveat is opt-in the same way on both paths. Done in this PR rather than a follow-up.

Re-verified with the build cache off: 155 unit + 37 Testcontainers IT (against apache/iotdb:2.0.8-standalone) green; checkstyle, spotless, apache-rat, and enforcer clean.

[CritasWang]

README is missing documentation for the new required property iotdb.ts_latest.cluster_mode

This commit adds a fail-fast constructor gate on iotdb.ts_latest.cluster_mode (must be sticky-routing or disabled), but the README was not updated:

• The configuration table only documents iotdb.attributes.cluster_mode; there is no entry for iotdb.ts_latest.cluster_mode.
• The latest-telemetry section still describes activation as just setting database.ts_latest.type=iotdb-table, with no mention that the new property is now mandatory.
  
  Impact: any deployment configured per the current README (with database.ts_latest.type=iotdb-table set) will fail to start after this change, and the operator has no documentation to consult — the only explanation lives in the exception message and javadoc.
  
  Suggestion: add a row to the README configuration table for iotdb.ts_latest.cluster_mode (mirroring the existing iotdb.attributes.cluster_mode entry: required when the latest DAO is active, allowed values, fail-fast behavior, and why the acknowledgement exists), and note the requirement in the latest-telemetry activation section. While at it, the new tuning knobs iotdb.attributes.executor.threads / iotdb.attributes.executor.queue-capacity should also be added to the table.

[PDGGK]

Done in 9534959 — added the README configuration-table rows for iotdb.ts_latest.cluster_mode (mirroring the iotdb.attributes.cluster_mode entry: required and fail-fast when database.ts_latest.type=iotdb-table is set, allowed values sticky-routing / disabled) and the iotdb.attributes.executor.threads / .queue-capacity tuning knobs, and noted the ts_latest.cluster_mode requirement in the latest-telemetry activation section so an operator activating the overlay has documentation to consult rather than only the exception message and javadoc. Thanks for catching it!