refactor(authlify): get authlify token from header

[dwwoelfel]

Which problem is this pull request solving?

The graph token is now available via the x-nf-graph-token header.

This will work better across different frameworks and require less effort to support a new framework.

List other issues or pull requests related to this problem

https://github.com/netlify/proxy/pull/767

Describe the solution you've chosen

This is fully laid out in https://www.notion.so/netlify/Graph-token-location-876947e0084447b49df96ec11248dd03, but I'll briefly summarize below:

This gets the graph token from the new x-nf-graph-token header instead of the event when used in a function or ODB. When used in a build, we retrieve the token from the NETLIFY_GRAPH_TOKEN environment variable.

It also exposes a getNetlifyGraphToken function that users can use to get the token instead of relying on event.netlifyGraphToken, which isn't available in e.g. next.js

Checklist

Please add a x inside each checkbox:

• I have read the contribution guidelines.
• The status checks are successful (continuous integration). Those can be seen below.

[dwwoelfel]

@ascorbic do people use @netlify/functions during their build steps?

We initially wanted to support getSecrets during build steps, but I don't think we've been emphasizing that and it causes problems using the same function for both the build and functions.

Is there a way for us to tell if anyone is using it during the build?

[ascorbic]

@dwwoelfel No, it's not something people usually do, but there isn't any particular reason it would be a problem. That said, conceptually it seems a bit odd having the same function. Would it be needing env vars injected by us when it's used? Presumably that would mean it wouldn't locally except via the Netlify CLI: somebody running next build or gatsby build directly would not have access to those? I would suggest having a new function (perhaps getBuildSecrets), possibly in @netlify/build, that includes specific checks to see that it's running in a Netlify environment (i.e. in CI or via the Netlify CLI) and fails if not with a helpful error message. It can check for process.env.NETLIFY to see that.

[ascorbic]

Looking good so far. Just a few points to make it more flexible mostly.

[anmonteiro]

Are we only changing the function name for the error message?

[dwwoelfel]

Yeah. I thought of making a function to create the error message, but thought it was overkill.

[anmonteiro]

LGTM