Pass req_opts to model calls

[nallwhy]

This PR resolves #347.

[brainlid]

Hi @nallwhy!

Thanks for taking the initiative to make this happen. I reviewed your description in #347 and you point out the following:

---

I see a few possible ways to address this:

1. Add a req_opts option to the global Langchain config (Not ideal in my opinion, as it applies globally and lacks flexibility.)
2. Allow req_opts to be set at the model (e.g., ChatOpenAI) level (But this feels a bit off, since it’s not necessarily model-specific.)
3. Allow req_opts to be passed through the LLMChain.run/1 function (I think this approach is the cleanest, as it keeps things explicit and per-request.)

---

And here you opted for approach 3.

I really appreciate your considerations on which approach makes the most sense.

In this situation, I actually favor approach 2. Here's why: A ChatModel is the thing that talks to the LLM for you. It isn't exclusively about the LLM's model config. Internally, it uses Req. It's appropriate for Req request options to be exposed on the struct and be used in the request.

Approach 2 is also a much cleaner change that doesn't risk breaking so many internal functions.

If we expect more types of request related config to be needed, then I could creating a Req config struct so the config could be standardized and struct defined functions could be used to apply the config.

Example of what I mean:

    req =
      Req.new(
        url: url(anthropic),
        json: raw_data,
        headers: headers(anthropic),
        receive_timeout: anthropic.receive_timeout,
        retry: :transient,
        max_retries: 3,
        retry_delay: fn attempt -> 300 * attempt end,
        aws_sigv4: aws_sigv4_opts(anthropic.bedrock)
      )
      |> ReqConfig.apply_options(anthropic.req_config)  # <-- something like this line

If the options is the only config you can see as applicable, then we can keep it simple and just do the options.

What do you think?

[nallwhy]

I see your point, and I agree.
It does seem more reasonable to store the config on the model and reuse it, rather than having to set it on every run call. It’s also simpler to pass around and feels safer.

As you suggested, I’ll add req_config as a map on each model (for now, I’ll start with just ChatGoogleAI to verify it works well) and rewrite it so the config is applied to the request.