Fix creation of PATs using UI on relative installations

What does this MR do and why?

Fix creation of PATs using UI on relative installations

When gitlab is installed using relative_url_root, the PATs UI fails to create new tokens. The listing, revoking and rotation works well.

The reason for this is that user_settings_personal_access_tokens_path contains the relative_url_root and when using the frontend buildUrl function adds relative_url_root again (in this example relative_url_root is /gitlab) :

1. user_settings_personal_access_tokens_path returns /gitlab/-/user_settings/personal_access_tokens
2. buildUrl with the above argument returns: /gitlab/gitlab/-/user_settings/personal_access_tokens

expose_url rails method doesn't fix this. expose_url should only be used for API paths, api_v[...]_path. Otherwise, it has the same net effect as buildUrl, https://gdk.test:3443/gitlab/gitlab/-/user_settings/personal_access_tokens.

On the other hand, user_settings_personal_access_tokens_url returns https://gdk.test:3443/gitlab/-/user_settings/personal_access_tokens . buildUrl detects absolute URLs and doesn't add relative_url_root. Hence, the problem is circumvented.

The final solution was to convert all URL to absolute and avoid using buildUrl in the frontend:

• For API path use expose_url
• For non-API paths use [...]_url

Changelog: fixed

References

Closes #550802 (comment 2589665293)

Relates to:

• !183415 (comment 2387443102)
• #439943 (comment 2590091709)
• #439943 (comment 2590115321)

Screenshots or screen recordings

No UI change.

How to set up and validate locally

1. Setup relative_url_root, for example "/gitlab", on gdk.yml
2. gdk reconfigure
3. gdk restart
4. Go to https://gdk.test:3443/[your_path from ]/-/user_settings/personal_access_tokens
5. Create a token

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.