Upgrade TypeScript and typecheck tests

[glasser]

Upgrading to TS 4 is generally useful, but it also lets use combine composite
with noEmit, which lets us actually use tsconfig.test.json.

This PR copies a few things we've done recently in the Federation repo.

• Upgrade TypeScript, Jest, and Codecov.
• Drop jest-cucumber dep (hasn't been used for a while).
• Update VSCode task to use the "typescript" type.
• Set enablePromptUseWorkspaceTsdk like in
  Configure VS Code to use the local TypeScript version federation#728
• Stop using moduleNameMapper in jest config, which seemed to create weird
  issues. Instead, just make sure that npm run compile happens before you
  run tests (at least when run via npm test) via a pretest script.
• Fix a lot of compilation errors (mostly caused by actually typechecking tests,
  though some from the upgrade). Most of this is pretty localized, but some
  required more work (eg, replacing a Map that was being treated as a
  KeyValueCache with an actual KeyValueCache implementation).
• I found the moduleNameMapper pulling in a top-level __mocks__ to be
  confusing and also led to errors about trying to import files from outside a
  project. In fact in general I found __mocks__ to be confusing. So:
  • I replaced our use of a custom Date mocker plus jest.useFakeTimers with
    @sinonjs/fake-timers (which does both and is what jest's is built on)
  • Replaced __mocks__/apollo-server-env.ts with a file that doesn't have
    a special __mocks__ name
  • Did the same for the ioredis mock, and loaded it into jest.mock explicitly
    rather than implicitly
• The thing where we imported a function that defined a jest test suite from the
  __tests__ of apollo-server-caching was sort of weird already, and
  importing from a project that used noEmit didn't seem to work at all
  here. So I changed the testing function to just be a normal non-Jest-specific
  function exported from apollo-server-caching that can be used in Jest tests
  (or non-Jest tests for that matter) with a bit of preamble. (I changed its
  name too so it's obviously a different function.) Because closing the cache is
  now not part of the test, we didn't need TestableKeyValueCache any more so I
  dropped it.
• isDirectiveDefined isn't exported and is now always called with an array, so
  remove code that runs if it doesn't get one and tests that that code works.
• RESTDataSource used to document and test that you can override baseURL in a
  subclass with a getter. This is illegal in TS4 so we don't officially support
  it any more.

Additionally, this PR removes global types from apollo-server-env (the
global.d.ts file). Thanks to @martijnwalraven for figuring this out and
writing the following:

We use exports from apollo-server-env to access the Fetch API to avoid
depending on running in specific environments. While environments like
Cloudflare Workers and Deno expose a Fetch API globally, in Node environments
you'd generally like to avoid polyfilling the global context. There are also
differences between the APIs available in these environments that we may want to
account for with our own types.

Unfortunately,apollo-fetch uses cross-fetch as a global polyfill (see
https://github.com/apollographql/apollo-fetch/blob/0a0b8df241960dfa72abf3bd179e9d936265a7da/packages/apollo-fetch/src/apollo-fetch.ts#L17),
and expects having Fetch API types defined globally.

Because we use apollo-fetch in our tests, we've long used a global.d.ts in
apollo-server-env to make the exported types available globally without
depending on the dom lib types (because most of the types in there don't
really make sense in non-browser environments and can lead to accidental usage).

As it turns out however, we also use superagent in our tests, and
@types/superagent now specifies an explicit dependency on dom lib. As
TypeScript makes any global type declarations available throughout a project,
that means our tests now get the dom lib types merged into their environment,
resulting in conflicts with the types in apollo-server-env's global.d.ts.

Forcing anyone depending on packages like @types/superagent to have their
environment extended with the dom lib types isn't great, and there are
existing discussions about the implications of this for that package
specifically (see DefinitelyTyped/DefinitelyTyped#41425). There is also a
promising proposal for a strictEnvironment option in TypeScript that would
help avoid these situations (see
https://gist.github.com/RyanCavanaugh/702ebd1ca2fc060e58e634b4e30c1c1c).

For now, I've solved this by reluctantly adding dom to
tsconfig.test.base.json. We should be able to remove this when our
dependencies get fixed or if strictEnvironment gets implemented.

I also fixed some typing issues that ironically illustrate the danger of having
these dom types available. Because the mocked version of apollo-server-env
exported classes through a const declaration, that didn't actually export them
as types, just as values (see microsoft/TypeScript#36348). But because we have
similarly named types defined in dom, those were used instead. Using named
exports in the apollo-server-env mock avoids this.

Fixes #5119.

[glasser]

@martijnwalraven OK, I made a bunch more changes, documented in the PR description, and I'm pretty happy with this. I squashed everything together including your change but I did preserve your commit message at the bottom of the single commit message / PR description. It looks huge but is somewhat repetitive so I hope you may be able to review it today?

[martijnwalraven]

This all makes sense to me. I would have preferred separating some of these changes into individual commits for tractability (like the global TypeScript types workaround), but no strong feelings about that.

[martijnwalraven]

I think this is a fine solution for now, to avoid creating a separate testing package. An alternative would have been to define a separate TypeScript project within the same package, which would have allowed the test to depend on Jest without those types affecting the production code. One benefit of that is that it would keep the ability to report individual test failures, as opposed to the first assertion throwing.

[glasser]

My concern is that I do want this to be easily available to other implementations outside of the repo, and the vague (perhaps flawed) research I tried to do on how to make a Jest suite "exportable" didn't turn up much. I didn't want to put a bunch of effort into something that might end up not working in different TS/Jest contexts when it seemed reasonably straightforward to write something that would definitely work all the time. Reporting individual test failures would be nice, but it's also like one page of code in a package that hasn't been a major focus of Apollo first-party development recently.

[martijnwalraven]

Alternatively, this could probably be typed using https://github.com/apollographql/apollo-tooling/blob/master/packages/apollo-graphql/src/schema/resolverMap.ts

[glasser]

ah will give that a quick shot

[martijnwalraven]

Same here: https://github.com/apollographql/apollo-tooling/blob/master/packages/apollo-graphql/src/schema/resolverMap.ts

[glasser]

fwiw I thought about leaving your commit separate but having separate commits where intermediate commits don't pass CI wasn't as attractive...