Use ImportResolver for table imports

[stevenfontanella]

Part of #8180. We currently replicate the existing behavior. In the future, we can also change ctor-eval to really simulate tables, and only use the EvallingRuntimeTable in the case of table imports. Removes existing pointer chasing logic that we repeat for each table operation (e.g. tableLoad, tableStore).

Allows us to fix spec tests where a table import becomes valid by resizing it in #8222.

[tlively]

I'd prefer renaming RuntimeTable to RuntimeTableBase so we can name this one RuntimeTable.

[stevenfontanella]

I wanted to give the interface the more canonical name since code should usually use the interface rather than the concrete implementation. I feel that giving the interface the name RuntimeTableBase is misleading because it implies that it isn't actually a RuntimeTable, and Base sounds like a base class instead of an interface.

I don't mind much either way. Another option is to hide RealRuntimeTable entirely by putting it in a source file and only exposing a factory function that returns unique_ptr<RuntimeTable>. WDYT?

[tlively]

I wanted to give the interface the more canonical name since code should usually use the interface rather than the concrete implementation.

Ok, that makes sense 👍

Another option is to hide RealRuntimeTable entirely by putting it in a source file and only exposing a factory function that returns unique_ptr. WDYT?

That sounds fine, too. I don't have a strong preference here.

[tlively]

Why take a reference to a bool rather than just copying it in?

[stevenfontanella]

It's set to true after instantiation link. I retained this logic from before, I think the intention is that tables may be mutated during instantiation by element segments, but not after.

Before it looked like this, now we need to capture a bool& because it's not a member anymore.

[tlively]

😱

Is there a plan for avoiding callback hell here? It seems like pairing subclasses of ModuleRunnerBase with subclasses of RuntimeTable et. al. so that they all know about each other would let us avoid this indirection.

[stevenfontanella]

I have two ideas but they would increase the footprint of this PR so I was planning to leave them for the next PR. For the outer callback, we don't need this as a param to ModuleRunnerBase, instead ctor-eval only needs to use EvallingRuntimeTable for imported tables, and we can return EvallingRuntimeTable from the ImportResolver. For non-imported tables we can use the real implementation that's already there in ModuleRunner.

For the inner callback of makeFuncData, I'm hoping this will go away once I do the refactorings for functions / function imports, but I'm not sure yet how it will turn out. Another option is to take the EvallingModuleRunner as an input instead of just the function but we'd need to move EvallingModuleRunner into its own header for that (because then EvallingRuntimeTable references EvallingModuleRunner and EvallingModuleRunner references EvallingRuntimeTable), and another downside is that it makes it harder to decouple from EvallingModuleRunner.

[tlively]

Ok, sgtm as long as we can simplify this eventually.