Revisit all @Transient usages in coroutines

[qwwdfsad]

Fixes #4293

[qwwdfsad]

See also: https://youtrack.jetbrains.com/issue/KT-73762/Warn-about-Transient-being-not-sound-to-use-with-non-nullable-types

[qwwdfsad]

In general, I cannot say that "trust me, this is safe" is, well, actually safe.

The problem with serialization is that it's impossible to reason about it in the bigger picture. We have our invariants, they are inherently local to the execution, and serializing-deserializing some of the things basically erases these invariants.
Even with manual readResolve, it still does not seem to be fixable semantically.

TL;DR Java serialization is bad, (see also: https://www.youtube.com/watch?v=fbqAyRJoQO0 by Java Architects), in other news -- water is wet

[dkhalanskyjb]

I have one minor remark about the contract of AbortFlowException, but I don't think it's a realistic concern; it's mostly a question of purity that can be ignored.

[dkhalanskyjb]

It seems possible to maliciously deserialize and use an AbortFlowException that would fail in ways that legal instances wouldn't fail. I'm not sure why not just mark owner as nullable: I don't think anything breaks if we have @JvmField @Transient val owner: Any? = owner where a constructor only accepts a non-nullable version. Why not do that instead?

[qwwdfsad]

I thought about that as well and decided not to do it: our general contract is that owner should be unique, which nullable type will immediately defeat -- and also will open the door for us to introduce new bugs (also, additionally cognitive load on handling nulls).

All of that, for the sake of the really malicious actor that probably can work around their ways anyway

[dkhalanskyjb]

also will open the door for us to introduce new bugs

I don't see the risk if

a constructor only accepts a non-nullable version

[qwwdfsad]

That's harded to follow in the code itself, the concept of "potential malicious actor" starts poisoning the signatures and makes readers/operators authors/etc. to read through that