Stream CsvDataTableStore.getRows from disk lazily instead of buffering the whole table

[krlittle]

What's changed?

CsvDataTableStore.getRows(...) read every matching CSV file fully into a List<Object> and returned that list's stream, so reading back a large data table held all of its rows in memory at once. It now selects the matching file(s) by their @name/@group comment header and parses each file lazily, one row at a time via the Univocity parser, behind a closeable Stream. Rows are produced on demand, so a whole table is never materialized in memory.

The change is intended to be behavior-preserving:

• same row order, prefix/suffix column stripping, group / @name matching, and typed-row (vs raw String[]) results;
• the writer is still closed eagerly at the getRows call, so a mid-run read still finalizes the file — only row parsing is deferred;
• error handling is unchanged: open/parse failures (which are unchecked) propagate, and only a stream-close IOException is swallowed.

What's your motivation?

Recipes that read their own data tables back — e.g. to export or aggregate them — can produce very large tables (one row per method/class across a large repository). Buffering the entire table into a List before the consumer sees a single row makes peak memory scale with table size; streaming bounds the store side to one row at a time.

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[sambsnyd]

Since CsvDataTableStore is used directly in the CLI you'll have to do a release which includes this before this will work at runtime. Recipe modules built with this running on un-updated CLI may encounter NoSuchMethodException here... unless you've verified that isn't true, you might want to guard invocation of this method with reflection until CLI with this method have been released for a little while

[natedanner]

Lazy streaming looks right and the happy path is fine (both RecipeRun callers collect(), fully draining). Two things worth addressing:

1. The returned stream now holds an open file handle until it's drained/closed. flatMap closes an inner stream only once drained, and the outer stream's close() doesn't reach a still-open inner stream — so a short-circuiting caller (findFirst/limit) leaks a handle even with try-with-resources. InMemoryDataTableStore returns a detached stream, so callers can't assume either way. Worth documenting on DataTableStore.getRows that the stream must be fully consumed/closed.
2. No tests for the new semantics; existing ones all fully drain, so a short-circuit leak wouldn't be caught.