Sparse set components in filters force sparse set iteration

[alice-i-cecile]

To refresh on sparse sets vs table component storages:

• Table iteration is 2-4x faster than sparse set iteration at the moment.
• Adding and removing sparse set components is faster than tables.

If a query has any sparse set components, we must use sparse set iteration as we don't have a single query. This is suboptimal if the sparse set components only exist in the filters, e.g Query<&Dense, With<Sparse>. All of the actual data we need to iterate over exists in table storage though, so this is a needless cost.

This is a common and natural pattern, especially if you're using sparse set marker components, so fixing this problem would help ensure that sparse-set components actually accomplish their promised perf benefits in real applications.

@cart raised this on Discord.

[cart]

Quick point of clarity: while the data we actually return is all in the table, the data required by the filter is not in the Table. We either need to store the data in the table (which likely significantly adds to the cost of maintaining the table + archetype moves) or we need to look up the archetype for each table entry as we scan the table and extract the component info required to evaluate the filter. Its very possible that both of these options end up being worse than the current implementation (which does normal sparse iteration in these cases, which means we already have access to the archetype when evaluating filters).

[james7132]

I made a first attempt at this with #4800, but it's currently unsound due to Fetch::filter_fetch there being infallible. We could make Fetch::filter_fetch return Option<bool> or collapse it via Option::unwrap_or(false). Might try to refine this so we can remove the filter dense checks if need be.