Allow File S3Adapter recieve an async function to retrieve config object

[Nikodermus]

The idea behind this is that the secretAccessKey is not directly accessible, but through a vault which is a async operation.

This way the S3 adapter can be used keeping the secrets, or being created with any kind of async operation in mind.

[changeset-bot]

🦋 Changeset is good to go

Latest commit: 1cbe0c7

We got this.

This PR includes changesets to release 1 package

Name	Type
@keystonejs/file-adapters	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Vultraz]

This feels a bit extraneous. What prevents you from just running the async code in a helper to fetch the value before constructing the S3 adapter?

[Nikodermus]

I have my lists that use the S3Adapter in different files, meaning they need the S3Adapter to be constructed by the time it's exported. There's no way to have the export to wait for the async code to be run before exporting the list

[timleslie]

I have my lists that use the S3Adapter in different files, meaning they need the S3Adapter to be constructed by the time it's exported. There's no way to have the export to wait for the async code to be run before exporting the list

I think I agree with @Vultraz on this one. You can always make your files export list-generator functions which can accept the adapter at the appropriate time, rather than relying on the S3Adapter to handle the deferred config generation.

In a more general sense, I'd like to avoid ending up in a place where all of our classes which take config work with object or async function as their argument. It makes it much harder to reason about the correctness of the Keystone library itself, which in turns makes it much more difficult to maintain.