Add demand control for uplink

[Y-Guo]

Implements https://github.com/mdg-private/planning/issues/727

This PR uses the new minDelaySeconds returned by uplink to set the polling interval instead of gateways polling every 10 seconds by default configurable on the gateway side. If no minDelaySeconds is provided by uplink, pollIntervalInMs will still be used.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[trevor-scheer]

Can we add a test that demonstrates gateway utilizing this value? Additionally, a new test that exercises the Math.max logic (largest value overrides) would be good too.

I'm wondering if pollIntervalInMs should be renamed, this new behavior might be surprising just based on the name of the config option. In what case would there not be a designated poll interval coming from uplink? Can we just fall back to 10s in the case that it's not provided and remove the option from managed mode configurations altogether? Open to ideas here, I'm just throwing out the first things that come to mind.

[Y-Guo]

I didn't use mocked timers here because there's an issue with jest and nock that me and Jeffery Burt couldn't figure out how to solve. Using real timers here as a workaround and not writing a test for the polling/math.max with pollIntervalInMs for this reason.

[Y-Guo]

cc @trevor-scheer

[trevor-scheer]

Thanks for the test addition 👍 The code changes LGTM.

I'm still concerned about pollIntervalInMs.

In managed mode, is there ever a case where the user's configuration is relevant after this change? Is it just the failure case?

I would be inclined to have a sane default which the gateway uses if it doesn't get one from Uplink and remove this notion of polling configurability altogether. Either that, or create a more appropriately named option for what this actually does now, which is more like fallbackPollIntervalInMs.

I think we should get some other opinions on this from @apollographql/atlas.

[Y-Guo]

From a quick look in the code it seems pollIntervalInMs is only used by the UplinkFetcher, IntrospectAndCompose, and LegacyFetcher.
Assuming legacy doesn't matter, IntrospectAndCompose is only initialized when isServiceListConfig() is true
BUT there's also a check that warns against using pollIntervalInMs and isServiceListConfig() at the same time!

[cpeacock]

I like the idea of setting it as fallbackPollIntervalInMs and creating less confusion with that value being far less useful as a result of this PR. I think you're right that legacy doesn't matter in this case because it's not using uplink. A sane default in the case of an outage may lead to a traffic stampede when service returns, so, while it's very unlikely to happen in practice, is something at the back of my head.

[trevor-scheer]

LGTM!