support user-configured authorization header

Issue Kind

Brand new capability

Description

I believe users would benefit from a behavior along the lines of:

• poetry config http-authorization-header.foo "<authorization header content, including the scheme>"
• export POETRY_HTTP_AUTHORIZATION_HEADER_FOO="<authorization header content, including the scheme>"

... where foo is name of the repository to which http requests should have the configured header.

Adding this feature would allow poetry users to use any private package index which supports use of the Authorization header, and should free the poetry developers from feature requests and issues dealing with any given private package index's authorization.

Note that I believe it is best to leave the choice of authentication scheme up to the user; that is, the user would be expected to set the string to something like Bearer <their bearer token>. This allows poetry to support any authentication scheme without additional work.

Like others, I have struggled to use poetry with a private package index. Ultimately, the challenge is in satisfying the private index's authorization requirements using poetry's available configuration knobs.

In the case of JFrog, they support:

• Basic authentication using username and password
• Using an access token instead of a password for basic authentication
  • in the basic auth <username>:<password> structure, this becomes :<token>
  • I believe such form was (inadvertently?) working until poetry 2.0.0; see #9977
  • I don't believe there is any way to get poetry >= 2.0.0 to properly authenticate with JFrog using ✨ only ✨ an access token
• Using an access token as a bearer token in an authorization header (Authorization: Bearer) with your access token

Impact

Adding this feature would allow poetry users to use any private package index which supported use of the Authorization header.

Workarounds

Whether or not poetry works today with a given private package index depends on the interaction of that index's authentication methods and poetry's available feature set.

In the case of JFrog, I do not believe there is any workaround using only an API token; there are JFrog use cases where there is no username, and these basic auth forms do not work:

• username=<token> password=<token>
• username=<empty string> password=<token>

No files, tests, or entry points are named. Start by locating Poetry's existing repository authentication configuration and HTTP request handling, then compare how configuration keys and environment variables are mapped. Done means a repository-specific Authorization header can be configured with the requested syntax and is sent for matching requests.