feat: Add dynamic authentication token forwarding support for vLLM

[akram]

What does this PR do?

Add dynamic authentication token forwarding support for vLLM provider

This enables per-request authentication tokens for vLLM providers, supporting use cases like RAG operations where different requests may need different authentication tokens. The implementation follows the same pattern as other providers like Together AI, Fireworks, and Passthrough.

• Add LiteLLMOpenAIMixin that manages the vllm_api_token properly

Usage:

• Static: VLLM_API_TOKEN env var or config.api_token
• Dynamic: X-LlamaStack-Provider-Data header with vllm_api_token
  All existing functionality is preserved while adding new dynamic capabilities.

Test Plan

curl -X POST "http://localhost:8000/v1/chat/completions" -H "Authorization: Bearer my-dynamic-token" \
  -H "X-LlamaStack-Provider-Data: {\"vllm_api_token\": \"Bearer my-dynamic-token\", \"vllm_url\": \"http://dynamic-server:8000\"}" \
  -H "Content-Type: application/json" \
  -d '{"model": "llama-3.1-8b", "messages": [{"role": "user", "content": "Hello!"}]}'
  

[akram]

/assign @grs
/assign @leseb

[ashwinb]

lgtm modulo a minor comment

[akram]

After more extensive tests, the initial implementation was insufficient to make the Response API and the Agent API where not properly using the provider data.

So, I had to add this second commit to implement it correctly. It was requiring the inference_api to be wrapped in a wrapper so headers can be extracted properly.

/assign @grs

/assign @ashwinb

@ashwinb can PTAL a second time?

[ashwinb]

This looks a fair bit complex. I believe there's an easier way or maybe the request state is not being propagated correctly. Will look into this in detail soon. Hold on...

[akram]

/hold

[akram]

@ashwinb you are right . I think I got confused with my own bug. It seems that by just adding the correct providers to agents and responses it forwards PROVIDER_DATA_VAR correctly.

can you PTAL ?

/hold cancel

[akram]

@mattf can you PTAL?