Add Common DB/Memory System: TraceMemoryDB

[doxav]

Summary
Introduce a unified memory for Trace TraceMemoryDB to capture rich execution traces optimization and training, support branching/rollback, and enable flexible retrieval across steps and solution candidates.

Spec & Discussion
Google Doc spec: https://docs.google.com/document/d/1HdpYa0RvhKsToI979Jnk4UVKal7YoMRFV1hI_fcALYI/edit?usp=sharing

Why?

1. Comprehensive, Immutable Data
   TraceMemoryDB records every invocation—parameters, prompts, code, scores, errors, feedback—into a single, add-only store. This audit trail makes it easy to debug failures, replay experiments, and meet compliance or reproducibility requirements.
2. High-Performance In-Context Retrieval
   An LRU “hot cache” for the last N entries plus optional vector-based search means you can efficiently fetch recent history or semantically related past events for richer prompt construction .
3. Flexible Workflow
   Built-in checkpointing, rollback, branching and lineage tracking let you explore sub-goals, fork experiments, and merge results without complex messaging between components .
4. Pluggable Backends
   Progressively swap in-memory mode for ChromaDB, Elastic, Milvus, PostgreSQL (to be defined)... to scale from local 1 process execution to multi-node shared-DB.

Request for your feedback:
– API design (constructor options, method signatures)
– Data schema and required vs. optional fields

Once we converge on the spec, I’ll start implementation on a feature/tracememorydb branch

[chinganc]

This is a very useful contribution.

We updated the contribution rule. Maybe this can be implemented under the directory opto/trainer instead of opto/features since I suppose later on there will be new algorithm or optimizer depending on it. (@allenanie, @adith387 thoughts?) We can add this after the 0.2.0 release.

Does implementing this require additional package dependencies?

Will give more comments later on.