[dwds] modules_tests are failing with addition of FrontendServer tests

[annagrin]

Problem

modules_tests are failing with addition of FrontendServer to dwds test infrastructure

Reason

The module tables changed due to introduction of FrontendServer test infrastructure and tests, since the same heuristic for getting a module name from module path does not work for all our setup scenarios:

• build_runner
• frontend server
• google3 build

The module tests now use a FakeWebkitDebugger to give dartSourcePath->moduleName information to be able to store module script IDs. However, we are still missing some information about usual google3 examples to make the tests actually ensure google3 scenario works in real world.

We need data from examples on google3:

• dartSource->moduleName mapping (already provided by FakeWebkitDebugger),
• moduleName->modulePath mapping
• _root variable for chrome_proxy_service (a directory off the root of asset server where index.html is served from)

Ideas

If we cannot make the google3 scenario work with current changes, we might need to modify the dwds code to adjust to all scenarios.

We can simplify the data lookup for module and location information if we use actual module names as keys, and off-load the mapping to require strategy for various scenarios. Then all code that adjusts the module names and paths to match can be removed (see DartUri, Locations, Modules.noteModule, Modules._initializeMapping)

For example, the following code in Modules.noteModule that attempts to guess the name of module from module path in chrome by assuming a dart file with the similar name exists in the same location

    var serverPath = _jsModulePathToServerPath(path);
    var module = await moduleForSource(serverPath);

    _scriptIdToModule[scriptId] = module;
    _moduleToScriptId[module] = scriptId;

Can be replaced with

    var module = globalLoadStrategy.moduleNameFor(modulePath);
    _scriptIdToModule[scriptId] = module;
    _moduleToScriptId[module] = scriptId;

Various scenarios

• frontend server:
  require strategy already knows the mapping, the root is always 'web'

• build_runner:
  require strategy has the mapping after loading the bootstrap file and can remember it (or evaluate customModulePaths variable). We would need to ask the asset server for the root of each module.

• legacy (google3):
  need to figure out how. Could just guess the module name from module path for now.

Notes

This could be the step forward to module interface solution (#910)