[TRNT-4339] Add timezone selector in UI

[antgamdia]

Description

This series of PRs aims to make the UI totally timezone-aware, depending on each user's preference. Not a browser preference, but a Trento user setting.

Next PR: #4169

Related # TRNT-4339

---

In this PR, we use an existing UI component to render a list of timezones and pass it as a payload for the user/profile settings. This PR is just about the frontend changes, nothing backend-related here.

The logic is simple: display a list of timezones. However, where does this list come from?
For instance, both Intl or the @date-fns wrapper we use have some support for timezones. One could possibly do Intl.supportedValuesOf("timeZone") to enumerate the timezones, and it works...
BUT: the list does not point to the latest version from IANA. For instance, in my browser, I just got Europe/Kiev but it was changed by the 2023c release (see source) to Europe/Kyiv.

By relying on a 3rd party dependency, we stay 100% aligned with any IANA tz release in the future. Note that this also updates the DST per country, so, in case of some political decisions around DST, the IANA database should quickly reflect that.

Some decisions:

• Only "Edit user" and "user's profile" will have the timezone selector
  • That means that when creating a new user, their timezone can't be selected ---> superseeded by [TRNT-4339] Allow setting timezone at user creation #4200
• Timezone for the default super admin is always Etc/UTC, and this is not modifiable (like other decisions)

Current status:

Note that for the UTC offset (like GMT+2) the current DST settings are taken into account. For instance, at the time of writing, Europe is in DST, meaning that we Europe/Madrid is GMT+2, but once in winter, it will be like GMT+1 again.

How was this tested?

IRL, unit and e2e tests

Did you update the documentation?

N/A

Additional information

Note: tests are currently failing because the backend is receiving more fields than it can handle. Subsequent stacked PRs will solve that.

Other proposals

There are some visual alternatives we can discuss, but they haven't been implemented in this PR:

Grouping by zone:

Adding country (requires yet another dependency)

[antgamdia]

Personal note: check #4192 once merged

[antgamdia]

Personal note: check #4192 once merged

Done at fb00436

[arbulu89]

Hey @antgamdia
I have written some "easy to fix" comments first.
Besides, I have some thoughts on how we save the timezones in this custom cache, and maybe we can do the next.
At the end, the code execution is blocked the first time we run the generateTimezoneOptions (unless we do it async), so why not simply have:

const timezones = generateTimezoneOptions();
export timezones;

Without any caching code, just a simple functional method.
I think the result is basically the same (this happens always at the beginning, not in the first page that needs it).
I don't know, the caching thing looks "premature optimization" for a couple of hundreds element list.

Otherwise, if we want to go fancy, we could do the same in a redux saga, but it looks an overkill.

What do you think?
Both are acceptable and similar anyway.

[antgamdia]

Feedback addressed; thanks a lot!

[arbulu89]

Great!
Really nice!

[antgamdia]

Merging to feature branch: TRNT-4339