fix: use epoch-based monotonic message ID for BanyanDB writes

[waterWang]

Fixes #13986

Problem

MeasureWrite and StreamWrite use System.nanoTime() as the message_id for BanyanDB writes. System.nanoTime() has a host-specific origin and is only meaningful for measuring elapsed time within one JVM — values are not comparable across hosts or host reboots.

In a multi-node OAP deployment, a host with a shorter uptime generates a smaller value. When DataPointValue.version is zero, BanyanDB assigns message_id to the persisted data-point version, so a genuinely newer update can be treated as an older version and rejected. Mutable measure fields such as last_ping stop advancing even though Kafka consumption and writes appear successful.

Observed ordering in production:

previous persisted version: 129399194960299109
newly generated version:     34229098907069822

Fix

Added AbstractWrite.nextMessageId(), an epoch-based, JVM-monotonic message ID generator:

• Base is the Unix epoch (System.currentTimeMillis() * 1_000_000), so current values are comparable across hosts and are larger than legacy uptime-based System.nanoTime() values in normal deployments.
• An AtomicLong with updateAndGet(Math.max(prev + 1, now)) guarantees strictly increasing values under concurrent writes and during temporary wall-clock rollback.
• MeasureWrite.build() / buildValues() now call nextMessageId(), explicitly set the same value as DataPointValue.version, and use it as message_id — matching the fix direction suggested in the issue.
• StreamWrite.build() / buildValues() use nextMessageId() for message_id as well.

Tests

New MeasureWriteMessageIdTest covers:

• message_id == DataPointValue.version in both build() and buildValues()
• strictly increasing message IDs across 10,000 sequential calls
• uniqueness across 8 threads × 2,000 concurrent calls

[wu-sheng]

This approach could ease the issue, but thr time clock adjusting could still be an issue.
Also, changing the version could make the existing deployment unable to update.