enhance: introduce retention policy to support truncated segment TTL

[tinswzy]

Background
Currently, truncated segments are immediately cleaned up once there are no active readers.
However, in some deployments, the writer and reader components are decoupled — the writer may truncate data promptly while the reader could lag slightly behind.
This can lead to scenarios where the reader fails to access recent data that has already been truncated.

Motivation
To improve data safety and avoid premature deletion, truncated segments should be retained for a configurable period before being permanently removed.
This retention mechanism ensures:

• Safe coexistence of independent writer and reader components.
• Prevention of data loss caused by aggressive truncation.
• Better operational control during transient read delays or restarts.

Proposal
Introduce a retention policy with segment TTL support, allowing truncated segments to remain accessible for a defined duration before cleanup.

[xiaofan-luan]

is there a way we can reserve the data until milvus data flush?

[tinswzy]

is there a way we can reserve the data until milvus data flush?

Yes, this change introduces a TTL retention time for truncated segments.
Segment truncation is triggered explicitly — it only occurs when Milvus performs a data flush.
After a segment is truncated, it will still be retained for the configured TTL duration before being deleted.
Truncated segments will only be cleaned up once their TTL expires and there are no active readers accessing them.