Multiprocessing support

[d-v-b]

I wanted to use this PR to add tests to ensure that basic array operations work in a multiprocessing context. But right now I just have 1 test, and it's failing with an infinite stall. Since this breaks the entire test suite, we should also fix the underlying bug in this PR. Stay tuned!

closes #2812

[d-v-b]

the underlying issue here is that store operations don't work in child processes.

[d-v-b]

I added some cleanup logic tied to os.register_at_fork that sets the persistent loops to None in child processes. No clue if this is the recommended approach, but it made the test pass. I also parametrized the multiprocessing test over different subprocess creation methods -- spawn, fork, and forkserver, with platform restrictions since not all OS's support everything.

[d-v-b]

@martindurant this seems like your wheelhouse -- would you mind checking this over?

[martindurant]

sets the persistent loops to None in child processes

This is absolutely what you must do.
asyncio event loops, threads and file handles are the main category of things that "don't work" in a child process, with the specific problem depending on which thing it is and how the process is made.

[martindurant]

(I should have added locks to the list of things to watch out for)

[d-v-b]

I think this PR is ready for review. The test I added checks that array indexing works in a multiprocessing context, which is a fine test, but the actual substance is whether our asynchronous store methods work with multiprocessing, and that can be tested without arrays. But I'd rather treat that as a test refactor for the future.

[martindurant]

I'm OK keeping these, effectively, as integration tests rather than store-specific. The top-level sync() we call internally is important here.

[martindurant]

strictly speaking, loop and iothread don't need to be global, since they are mutated in-place.

[martindurant]

Because windows should only perform spawn? This decorator is a bit verbose, it would be OK to put if ... : pytest.skip() in the body of the function.

[d-v-b]

I think I prefer (verbose) parametrization over checking the OS in the test itself. The former gives better feedback in the test summary.

[d-v-b]

maybe someone can explain what codecov is going on about? I find this hard to interpret:

I'm going to merge this later today unless there are objections.

[martindurant]

The "indirect changes" tab is picking up many lines in testing/stateful.py . I don't know why they show up here - maybe this file wasn't being tracked at all before?

[martindurant]

OK, it looks like not all of the coverage reports were in yet :)
Good now.

[d-v-b]

thanks for your help martin!