fix(context): Refactor context

[Josh-Walker-GM]

Problem
Context isolation was partially updated in v6 to remove a legacy flag which allowed disabling of context isolation. This unfortunately introduced some bugs for users which could not be further addressed without more potentially breaking changes. These were mainly centred around users who had introduced their own context isolation/handling into non-graphql functions.

Functions (other than graphql) have never had the assurance of context isolation out of the box - even though we allow direct access to the context in a function like we do in other places such as services. This is clear when you look at the results of k6 tests which test context isolation:

I do not think this is behaviour we should support. It is a confusing disparity in behaviour between graphql and other functions.

Changes

1. Moves context code into it's own package @redwoodjs/context. This is to avoid circular dependencies when it lives in either @redwoodjs/api-server or @redwoodjs/graphql-server. It is also a small package with no external dependencies which also helps to avoid bringing in unneeded code should it live in somewhere like @redwoodjs/api - although I am happy to move this into that package should we feel it'll only ever be used in conjunction with it.
2. Updates the context isolation mocking during user project tests.
3. Updates the context isolation tests in the test-project fixture.
4. Updates k6 tests to reference the new context package.
5. 'Hides' the getAsyncStoreInstance function as a dist import to discourage direct usage by users.
6. Adds a babel plugin to wrap all functions to ensure context is setup - in the event it has not been isolated at a server request level.

TODO

1. I want to confirm this plays nicely with users who have been using context in their api side tests.
2. I want to go through and tidy up any of this code which could do with it. We can likely deduplicate some code but I don't want to step on any of the other ongoing api server refactoring.
3. I also want to rename away from GlobalContext to something more descriptive like RedwoodAPIContext or similar.

^ The refactoring TODOs might not make it in here.

[Josh-Walker-GM]

Testing again with k6 tests shows that context works for the following:

yarn rw serve
yarn rw serve api
yarn rw dev
yarn rw-server
yarn rw-server api

The p(90) of the request durations where also pretty much the same before and after the changes added here. Of course this is all local and not results from deployed apps.

---

How to test?

1. I generated a test project with the familiar yarn build:test-project and then sync'd over the framework state.
2. In the tasks/k6-tests directory you'll find two context k6 tests: context_functions and context_graphql. These should be copied over to the test project, the root directory is fine.
3. You'll also find setups/context_magic_number in the k6 folder. You will want to copy the templates over too. The func.ts to the api/src/functions directory. The benchmark.sdl.ts SDL and benchmarks.ts service should be copied over into the api/src/graphql and a api/src/services/benchmarks respectively. Be careful if you copy these files from outside this current branch as they will have to reference the new @redwoodjs/context package and not the existing @redwoodjs/graphql-server package.
4. You can now build and serve the api side using all the possible ways to do.
5. You should now be able to run each k6 test with the following command:

   k6 run context_functions.js -e TEST_HOST=http://localhost:8911
   

   Noting that you may have to adjust the TEST_HOST to fit the particular serve method. E.g. to http://localhost:8910/.redwood/functions instead.
6. If the context is setup properly you should see the test pass otherwise it will fail. There will also be a summary.json written to the same location as the test files. This will contain the details of the test and may or may not be useful to look into.

This should all be possible with the yarn test:k6 command too but I tested manually just to confirm.

[Josh-Walker-GM]

@Tobbe and I discussed this PR and the suggestion was that we attempt to make this not breaking. We restore the original files in the graphql-server package so they remain for anyone using them but are marked deprecated.

I can't guarantee it is not breaking for people who have used our context related code within their own app in an attempt to get context working outside graphql. In this case they should be able to fix any issues by removing their custom code and relying on the functionality now being provided by the framework.