Skip the inline snapshot lookup when a commit only starts streams

[lahma]

What was wasted

When a session that only starts streams is saved with an inline single-stream snapshot, every commit still ran a separate query before the write batch:

select d.id, d.data, d.mt_version from <schema>.mt_doc_<aggregate> as d where id = ANY($1)

That query always returns no rows. It costs one round trip for each commit that starts a stream. With UseIdentityMapForAggregates off, which is the default, it also opens a second connection, because the load goes through LoadManyProjectedAsync.

Why

JasperFxSingleStreamProjectionBase (in JasperFx.Events) asks projection storage only for the ids of streams with StreamActionType.Append. A commit that only starts streams therefore passes an empty id array. ProjectionStorage.LoadManyAsync passes the empty array on to LightweightDocumentStorage.LoadManyAsync or to LoadManyProjectedAsync. Neither of them short-circuits an empty array. IdentityMapDocumentStorage already returned early in that case (#5258), but lightweight sessions and the projected path did not.

The change

ProjectionStorage.LoadManyAsync now returns an empty dictionary when it is given no ids. That one place covers every caller: single-stream and multi-stream inline projections and the daemon's AggregationRunner, with UseIdentityMapForAggregates on or off.

Why it is safe

The set of streams that get looked up does not change. The empty array was never going to find anything, so skipping it changes no result:

• Appends still load their existing snapshot.
• In a batch that mixes a start and an append, only the appended stream is loaded.
• Starting a stream whose id already exists still throws ExistingStreamIdCollisionException at commit, and the existing snapshot is left unchanged. That id was already excluded from the lookup before this change; only the empty query is gone.

Tests

New file: EventSourcingTests/Projections/inline_snapshot_reads_when_starting_streams.cs. It counts the selects against the aggregate's table through Npgsql's ActivitySource, so the separate connection used with the flag off is counted too. Every case runs with UseIdentityMapForAggregates both on and off:

Case	Reads
Start a stream	0 (was 1)
Start string-keyed streams in two conjoined tenants	0 (was 2)
Append to an existing stream	1
Start one stream and append to another in the same commit	1
Start a stream with an id that already exists	throws ExistingStreamIdCollisionException; snapshot unchanged

Before the fix, 4 of the 10 cases failed: the start-only and two-tenant cases, with each flag setting. After the fix, all of them pass, and so does inline_cache_hit_query_counts. The full EventSourcingTests run on net10.0 passes, except for the five testing_projections tests that hard-code localhost:5432; my local database was on a different port.

[jeremydmiller]

@lahma Good catch. I thought we already had that optimization