[BigRoy]

Changelog Description

Creating a connection with a token (ServerAPI, GlobalServerAPI, create_connection) makes 1 request on 1 connection. Before, it made 3 requests on 3 connections, or 4 on 4 with an API key.

Part of ynput/ayon-launcher#129.

Additional info

Before, a connection with a token requested, each with requests.get and therefore each on a new TCP/TLS connection:

1. GET / (web frontend page) to check availability
2. GET /api/info
3. GET /api/users/me with Authorization: Bearer
4. For an API key, the Bearer request always gets 401, then GET /api/users/me with X-Api-Key

Now:

• Availability check and token validation share one request, GET /api/users/me. A 200 or 401 response means the server is available. Any other response falls back to GET /api/info, which replaces GET / as the availability check.
• Tokens that aren't 64 characters long are sent only as X-Api-Key. The server accepts only 64-character tokens as Bearer (parse_access_token in ayon-backend, since 0.5), so the Bearer attempt for a 32-character API key could never succeed. 64-character tokens still try Bearer first, then X-Api-Key. Trying X-Api-Key first, or sending both headers, isn't an option: the server checks X-Api-Key first, and an invalid API key costs a 0.2 s server-side delay plus a brute-force counter hit.
• Validation requests use a session, which then becomes the authorized session, so the first API request reuses the same connection.
• create_session doesn't validate an already validated token again.
• validate_token no longer requests /api/info first. It does so only when users/me returns an unexpected status, so a URL that isn't an AYON server still raises.
• get_user_info_by_token has an optional session argument.

Behavior changes:

• create_session() no longer re-validates a token that was already validated. A token that became invalid since is still caught: the first request gets 401 and marks it invalid, as before.
• The availability check without a token requests /api/info instead of the web frontend page.
• A URL of a server that isn't AYON raises ServerNotReached. Before, the error depended on whether that server answered / with 200.

Measured in AYON launcher startup, together with ynput/ayon-launcher#346, against a local server with 50 ms latency added per request and per new connection:

Scenario	Before	After
User token	13 requests, 8 connections, 1.93 s	4 requests, 1 connection, 1.31 s
Service API key	15 requests, 10 connections, 2.08 s	4 requests, 1 connection, 1.16 s

Not changed here: get_user_by_token returns user_info.data, but UserInfo has no data field, so it raises AttributeError whenever the token is valid.

Testing notes:

1. pytest tests/test_token_validation.py (no server needed).
2. Create a connection with a user token and with a service API key. Check that each makes one request (e.g. in server logs or with a proxy).
3. Create a connection to an unreachable URL (raises a connection error), and to a URL that isn't an AYON server (raises ServerNotReached).