[Feature Request] Research and maybe implement disallowing all Ruby stdlib sync constructs in workflows

[cretz]

Describe the solution you'd like

In Ruby, sleep, Timeout.timeout, Mutex, ConditionVariable, Queue, and SizedQueue are all fiber-aware and therefore we implicitly make them durable which is a nice property. So users can use their normal constructs and they "magically" work. But there are cases where third party uses of these are expected to be same-process only. We hit one where logger uses a mutex and we therefore durably blocked the mutex and completed the workflow task, but the local-process unblock happened after we had removed our fiber scheduler so it was not durably unblocked leading to hung workflows.

The proposal is to, before GA, consider all of these standard library things illegal via illegal call tracing. This will help users catch when libraries are accidentally doing something illegal that they need to opt-out of the durable scheduler for. This means that we need to provide workflow-safe equivalents. We already do for sleep and timeout, but we need to forothers. The current thought is to basically do a Delegator type approach to the standard library ones that does opt-out of illegal call checks.

It is important to land this before GA since it is backwards incompatible. By being extra restrictive here, we can choose to relax things later if we want.

[cretz]

We have hit our first snag here. While trying to disable use of Mutex in workflows, it turns out every Google Protobuf field access uses a mutex. It may not be reasonable for us to wrap every proto access in a disable-tracer block nor may it be reasonable to ask users to. It is also too expensive and fickle to inspect the stack to allow only Google Protobuf to use mutexes and nobody else. However, if we leave Mutex for general use like it is used in loggers, technically it may hang workflows if you use stdlib Logger with Mutex (and maybe other places), see #309. Not sure what to do here, discussing with team...