✨Add AMP layer to E2E tests

[cvializ]

Related to #20457

This PR also reduces the height of the windows in some tests, since not all screens are large enough to allow windows to resize to be 1000px.

@estherkim and I discussed configuring experiments using the top-level configuration object, like the integration tests currently do, e.g.

describes.e2e('amp-blah', {experiments: ['amp-blah-experiment']}, () => {
  /*...*/
});

We will work toward that. That code will consume the AmpDriver instance and we can factor out the toggleExperiment calls at that time.

[estherkim]

Would it be too much to use TestSpec in describes-e2e for this PR (top level config as you mentioned)? Then you'd only need 1 single toggleExperiment call in setting up AmpPageFixture and it'd be cleaner from the get-go.

[estherkim]

Do we need a separate AmpDriver file? My understanding is that it's only used to set up AmpPageFixture. It would be a somewhat straight forward change if we move AmpDriver.toggleExperiment() into describes-e2e if we use TestSpec for test config since it's already carried through in the constructor.

[cvializ]

I think there will be other use-cases for AMP-layer concepts in future tests, so to me it makes sense to have a separation of concerns where there is a specific AmpDriver class that's responsible for reads and writes to AMP-related state setup, and the AmpPageFixture class is responsible for reading any configuration and preparing the drivers/browsers.

I haven't solved the problem of experiments needing to be set when the browser is on a page on the domain that the test code runs on. And that problem needs to be solved before moving the toggleExperiment call into describes-e2e. For example, tests can open pages on any domain, but describes-e2e doesn't have knowledge about the pages that will be loaded, and the experiment will only be set on the browser's current domain. I think to maintain incremental progress that we should solve that problem in future PRs.

[sparhami]

A bit unclear here, [fn].concat(args) looks to be the same thing as arguments, so why not just apply executeScript with arguments directly?

If you do want to do this pattern (e.g. if typing is an issue), this would be better:

eval_(fn, ...args) {
  return this.driver.executeScript(fn, ...args);
}

[cvializ]

I didn't want to use arguments directly because I wanted to enforce the use of a function as the first argument, since I believe Selenium's executeScript also accepts a string. The spread operator works better, thanks

[sparhami]

The style guide says trailing _ for @private methods, fields, etc. but does not say to use them for @package. Should remove the _.

[sparhami]

@private?

[cvializ]

It'd be nice if we could run Closure Compiler to actually enforce the type information on these methods, but since these aren't really compile targets I'm not sure how we'd do that.