arrow

ARROW-9815 [Rust] [DataFusion] Fixed deadlock caused by accessing the scalar functions' registry.

@andygrove and @alamb , I have no formal training in thread and mutex management, so I am not certain about this proposal or the following explanation:

My understanding is that because the result of

```
ctx_state
                .lock()
                .expect("failed to lock mutex")
                .scalar_functions
                .lock()
                .expect("failed to lock mutex")
                .get(name)
```

is of temporary lifetime, using this in `match` blocks any access to `scalar_functions` until we leave the match, which deadlocks when we recursively call the function. Here I just cloned `.scalar_functions` so that we allow the lock to be released.

I may also be dead wrong on every word that I wrote above.

This does work, but if you could validate my reasoning above, I would appreciate very much!

Note that we are also doing the same for `.datasources` in this file, which I suspect will also deadlock if when we have a plan with two sources. I did not touch that as I do not know the idiom/pattern to address this (locking within recursions).

An alternative solution for this is to not make `PhysicalPlanner::create_physical_plan` recursive, and instead call a recursive function (with all the current logic of `create_physical_plan`) with references to `datasources` and `scalar_functions`, so that they can be used recursively (and we do not have to lock on every recursion.

Closes #8018 from jorgecarleitao/fix_deadlock

Authored-by: Jorge C. Leitao <jorgecarleitao@gmail.com>
Signed-off-by: Andy Grove <andygrove73@gmail.com>