fix(copilot)!: allow overriding headers, api_base

[80avin]

We are using organizational version of Github copilot and I used to get unauthorized error, similar to #1052 ,

Digging deeper into the vscode's Copilot-chat extension, I found 2 differences which are required to fix this

1. API calls are made to api.business.githubcopilot.com
2. It doesn't work unless I set the headers as

   ["Editor-Version"] = "vscode/1.98.2",
   ["Editor-Plugin-Version"] = "copilot-chat/0.25.1",

As a solution, this PR implements

1. Use the base URL provided in auth response.
2. Allow overriding the headers: They can be overridden by creating another provider and having self as function argument helps this case.

Note: I haven't tested github_models because they weren't working under my credentials.

[deathbeam]

I would rather fix the actual issue. I dont like this solution because I am intentionally keeping the provider interfaces simple, and also its not even actual solution because the user is expected to override the headers until it starts working. But for example zed is using the static url always, and github usually properly redirects them too:

https://github.com/zed-industries/zed/blob/f15a241d3ef93241a09afd5052d6aef29ea48e9b/crates/copilot/src/copilot_chat.rs#L17

And they also do not need to fake that they are going through vscode:

https://github.com/zed-industries/zed/blob/f15a241d3ef93241a09afd5052d6aef29ea48e9b/crates/copilot/src/copilot_chat.rs#L375

[deathbeam]

But sending self might be fine but I dont think you need to add the changing api base anywhere else other than copilot provider, in embeddings simply use value from there when building the url and thats it and you dont need to do any changes to github_models. And it def shouldnt be part of the type definition. But def remove the default_headers, you are supposed to make your own provider when doing that (which is very simple you just reference the methods from your custom implementation and thats it right)

[80avin]

@deathbeam, I agree with you.
I was also uncomfortable with the overriding of headers as it felt misplaced. The idea of custom provider didn't hit me.

Anyways, do you agree with keeping the api_base? A few points:

1. Github's API response itself tells us about using a different endpoint, and the official copilot-chat extension respects this. Hence, it sounds fair if we also do the same.
2. If api_base is a separate variable like current, I can essentially extend the copilot provider in my config to override get_headers and api_base instead of writing a new provider entirely.

[deathbeam]

Well I dont want to keep api base as part of the default api, it should be copilot provider specific. you can always refer to it from other providers in the actual functions, and updating it from the inside of copilot provider. E.g its very specific to the copilot provider so it should just stay there imo.

[80avin]

@deathbeam Can you review now ?

For others, the following lazy.nvim config shows how I'm able to override them.

{
    "CopilotC-Nvim/CopilotChat.nvim",
    -- url = "https://github.com/80avin/CopilotChat.nvim",
    opts = function(opts)
      local providers = require("CopilotChat.config.providers")
      local orig_provider = providers.copilot
      ---@diagnostic disable-next-line: inject-field
      orig_provider._cache_get_header = orig_provider._cache_get_header or orig_provider.get_headers
      local orig_get_header = orig_provider._cache_get_header
      orig_provider.get_headers = function(self)
        ---@diagnostic disable-next-line: need-check-nil
        local headers, expires_at = orig_get_header(self)
        return vim.tbl_extend("force", headers, {
          ["Editor-Version"] = "vscode/1.98.2",
          ["Editor-Plugin-Version"] = "copilot-chat/0.25.1",
        }),
          expires_at
      end
      providers.github_models.disabled = true
      if true then
        return nil
      end
    end,
}