spawn_system_task should not propagate ContextVar state

[njsmith]

Probably we should make spawn_impl have a system_task flag instead of its current ki_protection_enabled flag. We already have to special case init as not inheriting TaskLocals, so this would remove that special case (since init is a system task).

[Fuyukai]

Is this still relevant, given the ContextVar change? The system task context could potentially be reset to a regular context() rather than a copy_context() (if I understand the issue correctly), otherwise this can be closed.

[njsmith]

It's still as relevant as it was, just now it applies to ContextVars instead of TaskLocals :-).

The intuition is that a "system task" is a global resource that's not particularly associated with any task, so it shouldn't retain the context where it happened to be spawned. I think I was thinking about this in the context of #303, where the idea is to use system tasks to model the case where you want a single task to be part of multiple parts of the task tree at the same time; in this case it doesn't make sense for ContextVars to be inherited from whichever task happened to start the new one first.

Given how contextvars are more general than a single system, I guess the way to do it would be to stash a copy somewhere of the context that trio.run is called with, and then for system tasks copy that instead of the creator's context.