IndexBuildInterceptor creates it lazily today and that makes the resume handling a bit complicated. To be able to resume correctly, we create the table in multi_index_block.cpp (when saving the state) if it has not already been created. We also create it in index_build_coordinator.cpp if the resume info does not have it (old versions of mongod). We can get rid of the code in multi_index_block.cpp if we always create this proactively like we create the side writes table and the duplicate key tracker table.

This is also required to ensure that both the primary and the standby create this table as of the same timestamp (i.e. startIndexBuild timestamp). Otherwise, ingest table could panic.

We attempted it previously once, but that caused BF-38757. I proposed changing the perf workload to avoid some of the false positives. If PERF-7099 has been fixed, the perf regression "should not" appear again.