Prefer to use URLs to encode the current organization

What does this MR do and why?

Prefer to use URLs to encode the current organization

Not having the organization in the URL implies that the current organzation will have to be in the session - this will be much harder to keep a consistent organization for multiple requests when the user has multiple tabs open.

Related issue: #419959 (closed), #411637 (closed)

Why?

Today navigating to https://gitlab.com/tkuah generates the following requests:

• https://gitlab.com/users/tkuah/activity?limit=10
• https://gitlab.com/users/tkuah/projects?limit=10&skip_pagination=true&skip_namespace=true&compact_mode=true
• https://gitlab.com/users/tkuah/calendar.json

Imagine user switches organization in one tab, and also navigates to the user profile in another. Wouldn't the user profile end up with data from two different organizations ?

We have a few options :

1. Redirect https://gitlab.com/users/tkuah/calendar.json to https://gitlab.com/organizations/<default_organization>/users/tkuah/calendar.json. Also, redirect https://gitlab.com/users/tkuah/calendar.json?organization_id=X to https://gitlab.com/organizations/<X>/users/tkuah/calendar.json.
2. Respond to https://gitlab.com/users/tkuah/calendar.json with data for the organization stored in the session. When user switches organization using the organization switcher, the organization in the session is updated.

Which option is preferable ?

Evaluation

Option 1 should allow multiple tabs. Option 2 is less flexible.

Option 1 also follows today's way of encoding the current group / current project in the URL, e.g. https://gitlab.com/gitlab-org/gitlab/-/merge_requests, and not having current group / current project in the session.

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.