Asynchronous materialization of samples view

[XingY]

Rationale

On server start or after sample designer update, the first request to load the sample grid for a large sample type triggers a synchronous full table materialization, which can take a long time if the number of sample rows is large. If the user navigates away before it completes, the HTTP request is cancelled mid-flight, aborting the SELECT INTO. The materialized view is never populated — subsequent visits repeat the same blocking behavior indefinitely.

This change decouples view population from the request. When the materialized view is not ready (never built, or stale due to pending incremental updates), the request falls back immediately to direct JOINs and submits a background rebuild. The background task runs to completion regardless of user navigation, so the next visit uses the fast materialized path.

Related Pull Requests

Changes

• ExpMaterialTableImpl: replaced the synchronous getMaterializedSQL() call with the async-aware path.

[labkey-matthewb]

It seems redundant to have isReadyToUse() and tryGetFromSqlIfLoaded()? Is there a caller of isReadyToUse() that doesn't immediately want to proceed to use the table?

sql = tryGetFromSqlIfLoaded();
if (null == sql)
     start asyncLoading
     sql = getJoinSQL(selectedColumns)
...

[XingY]

There is a case when there is a lookup defined on samples table, getJoinCondition is called again even though it was previously already determined:

platform/api/src/org/labkey/api/data/LookupColumn.java

Line 224 in 4d996df

if (assertEnabled || !map.containsKey(colTableAlias))

Could we actually remove the "assert" check here? Absent of it, the lookup join sql won't be attempted again and we can simplify the materialization logic for samples.