Allow infinite TTL (time-to-live) on KeyValueCache's set.

[abernix]

Previously, while it was possible to set very high TTL values on individual sets, it was not possible to say "Do not assign a TTL value.". This adds that possibility.

Furthermore, this allows the persisted query cache configuration (and its options PersistedQueryOptions) in Apollo Server to specify a setting and, when specified, to pass that option into the set used in ApolloServer.

Of course, that still necessitates passing a default that's isolated to Apollo Server itself, rather than a default that's able to be specified when constructing the cache.
There's another approach to solving this problem which might be worth (still? in partial replacement of?) allowing, but I couldn't convince myself of the approach.

The alternate pattern would allow the instantiation of the cache itself to override its previously hard-coded defaultSetOptions (for example), but I found that approach unfortunately complicated by varying constructor signatures on those classes which implement KeyValueCache.

In particular, they didn't seem to share a common pattern which had a home for such options that didn't necessitate the new option object becoming the second or third argument on those constructors. For example:

RedisClusterCache's

apollo-server/packages/apollo-server-cache-redis/src/RedisClusterCache.ts

Lines 17 to 18 in d025580

	constructor(nodes: ClusterNode[], options?: ClusterOptions) {
	this.client = new Redis.Cluster(nodes, options);

RedisCache's

apollo-server/packages/apollo-server-cache-redis/src/RedisCache.ts

Line 16 in d025580

constructor(options?: RedisOptions) {

MemcachedCache's

apollo-server/packages/apollo-server-cache-memcached/src/index.ts

Line 15 in d025580

constructor(serverLocation: Memcached.Location, options?: Memcached.options) {

Please review commit-by-commit messages for further details.

[abernix]

@trevor-scheer Can you try to convince me to change this parameter to be ttl, rather than ttlSeconds?

Considerations:

• Against: It's come up a number of times before that parameters that define units of time could be more clear by specifying their precision as part of the name. (This is the only reason I actually put Seconds in the name.)
• For: The existing interfaces which this translate to are still ttl, for better or for worse, but that's what they are.
• For: It's not "seconds" when set to null, so ttlSeconds: null is a bit peculiar.
  • Along the same lines, this PR changes those existing interfaces to also support null.
• For: While including the precision makes sense in many cases, TTLs are very often (e.g. Memcached, Redis, HTTP Cache-control, and so on). On the other hand, lru-cache sets its maxAge in milliseconds. To be honest, I find such flexibility unnecessary. Is it truly wise to cache things with sub-second precision?
• For: Thanks to the TSDoc annotation provided directly above this, users with editors that support it are automatic given IntelliSense clarity that this in seconds.

[abernix]

Of course, anyone should feel free to chime in on this naming puzzle.