[Proposal] Allow configuring the Task module implementation.

[Rudolf Manusadzhian]

Hi there! I want to make a proposal for allowing Ecto users to configure what module to use to run Tasks (for preload and whatnot).

One example users might want to replace Task module with a wrapper OpentelemetryProcessPropagator.Task. Surely, the library authors came up with a reverse propagation scheme and mention that it might be useful for cases such as Ecto.preload, However, it still looks very hacky,  doesn't work out-of-box with OpentelemetryEcto, requires a manual boilerplate around every function that calls Ecto.preload

One example of the library providing with such configuration is Tesla.Middleware.Timeout

plug Tesla.Middleware.Timeout,
    timeout: 2_000,
    task_module: OpentelemetryProcessPropagator.Task

[Felipe Stival]

I'm in favor of this change. Opened a PR: https://github.com/elixir-ecto/ecto/pull/4245

With the proposed API, you'd be able to set `default_options/1` in your Repo in a way that all your preloads uses the alternative Task module:

```

def default_options(:preload), [stream_fun: &OpentelemetryProcessPropagator.Task.async_stream/3]

def default_options(_), do: []

```

[Yordis Prieto]

I went for an entire module in the Tesla implementation rather than a function because I needed more than one function from the module, so a bit different.

After seeing this a few times in the ecosystem, I pass the entire Task module rather than a single function. Bikeshedding aside, Func vs. Mod; started becoming such repeatable pattern/intent that I instead see almost the exact same implementation of configuration anywhere.

Being said, either way, will work! Definitely a good addon.

[Felipe Stival]

Due to some concerns with tying preload with Task, we changed the proposed API a bit, but you still should be able to achieve the same results as previously mentioned. Reviews/comments in the PR are welcome.

Before merging, I'd also like to understand more about the use-case. You mentioned that the reverse propagation mechanism doesn't work with opentelemetry_ecto, but I see some usage. It isn't obvious to me which cases we would cover that aren't already covered by the reverse propagation already implemented there. Could you please elaborate?

[Rudolf Manusadzhian]

Thank you for looking at it and the work!

Another example of propagating a context in our application we are doing is :logger metadata via :logger.get_process_metadata/0 and

:logger.set_process_metadata/1 in task.

That allows to set logger filters based on metadata.

But, now I feel dumb that I didn't notice reverse propagation being used by opentelemetry_ecto, I just occasionally see orphan spans and thought it's still that old known issue with Repo.preload.