Refactor hardcoded Subscription Portal URLs into direct routes

What does this MR do and why?

In order to link the local application to address in the external Subscription Portal, we have used a few patterns to memoize the URLs. The current approach has issues with the zeitwerk autoload and adds unnecessary complexity by reinventing the routing routes in a non-standard way.

Rails has support to a way to define "direct routes" (arbitrary paths pointing to an external URL of any format): https://guides.rubyonrails.org/routing.html#direct-routes

This MR refactors and extract the many routes that are being saved in constants, and move them to be direct routes.

Because the routes require the codebase to already be loaded, and the codebase would have to rely on the routes to finish if we want to reuse it in a partial MR/splitted, it's not possible to split it.

The reason why this MR exists it in fact to fix this inter dependency at load time.

Here is an example on what the existing code causes when running GitLab in development mode:

How to set up and validate locally

Tests should validate it works as it is refactor

To review please go commit by commit as each extraction was isolated in each commit.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.