Dedupe sync/async paths of recursive delete code

[crwilcox]

https://github.com/googleapis/python-firestore/pull/420/files#diff-ae4779c3bae12c581abba3732b4ed80ab155b08787b617798a06e36cb0642052R342

Currently the sync/async versions of recursive delete are pretty similar. A thought: What if the sync version managed accessing the event loop, using the async implementation, and blocking.

Perf should likely be investigated when doing this but it may be a way to avoid duplicate code throughout the two halves if the event loop doesn't add significant overhead.

[daniel-sanche]

We investigated something similar for bigtable, but came across this forum thread:

async code is written under the assumption that the sync code it calls never blocks for I/O, and definitely never enters the event loop recursively. Only await may enter the event loop. This is used in many places to avoid explicit locks: async code can rely on the fact that no other code runs concurrently unless explicitly allowed by await.

It seems that calling into the event loop through the sync function is not supported and can result in deadlock. We did some experimenting with sync code generation from an async implementation, and that might be a safer way to avoid maintaining duplicate code