Cleanup: Consider unifying sync and async code paths

[anpete]

Using the pattern where we use async methods all the way down, but pass a flag that controls whether the actual I/O operation is performed asynchronously. See Npgsql for example.

[AndriySvyryd]

@smitpatel not needed?

[smitpatel]

I don't remember what was basic idea was before. But this is what current mechanism in place.

• Query Compilation is agnostic to sync/async except
  • Generating final QueryingEnumerable which would be used to enumerate database result
  • Reducing cardinality of result on client side when final result is not enumerable
• Shaper is also sync agnostic. We only use sync/async to read row from database side in particular mode. And of course the cancellation token for async enumeration.

If there is anything else we can do and should do then we can update description accordingly. Nothing specific comes to my mind. Up to @AndriySvyryd and @roji

[roji]

We still have quite a few places in EF (outside query compilation) where we have code duplication for sync/async, I think there's value in doing this - unless there are objections.

One theoretical issue is that this introduces a slight CPU perf hit on the sync path because methods are now async, i.e. have a state machine, even if they always complete synchronously. That's likely to be completely negligible though.