Added e2e tests for alerting

[skrech]

Description

This PR adds E2E tests for the alerting configuration. Since alerting configuration supports setting it from either environment variables or from the DB different setup is required for running the backend. This necessitates splitting the tests into two groups -- one for the case where environment variables are in place and no dynamic configuration is possible and the second one is when the config is read from the DB and can be modified by the user in real time using the Web API.
The former case can be considered as the default behavior and its tests are run along the rest of the parallel test suite.
The later case is protected by an env var ALERTING_DB_TESTS and has its own custom GitHub Actions job.

Added is a new dependency -- pg package which allows to directly interact with the Postgres DB in some of the alerting configuration tests since there is no other way to control the fixture by solely using the API.

Updated is the developer documentation on how to enable setting alerting configuration via the web API during development.

[nelsonkopliku]

Looking good, @skrech!

CI changes are expected in this PR or a different one?

[skrech]

Added the CI changes. Instead of creating a new Job, though, I went for re-using the test-integration job. It's definition is generic enough and the only redundant step is starting the idp profile for docker compose (but this causes no harm for alerting).
I'd even suggest we rename the test-integration job to something more generic like e2e-parameterized, for example - effectively it takes all the steps necessary to parameterize e2e test -- setting cypress env-vars, modifying the compile-time elixir configuration and specifying what spec files to run. We can also add the docker compose profile in the matrix and then it would become truly universal.
I had to re-arrange settings.cy.js for better skip handling. It turned out in the case where we're using the test-integration job the subset of desired alerting tests are run along with the tests for suma, activity log, etc. To avoid that with as little change to existing files as possible, I decided to split the alerting tests involving DB interaction into their own file settings_integration.cy.js following the de facto convention established by sso_integration.cy.js. This works great, IMO apart from the somewhat misleading name -- settings_integration, there is no integration actually going on.
I also added a small protection mechanism to skip the enforced-from-env test if they are run against local development BE target currently using the DB for configuration.
With that, this PR seems to be complete. All CI checks are passing. If there is a consensus on leaving the SQL excerpt as is, then I think it's in a good shape to be merged.

[nelsonkopliku]

Looking good, @skrech!

As mentioned privately I was confused by the fact that from the test setup it looks like the default behaviour is env var driven alerting settings, which I understand being the case for development.

However, if I recall correctly, for the user the default behaviour is database driven, right?

[vicenteqa]

looks nice @skrech !

[nelsonkopliku]

Nice, thanks!

[nelsonkopliku]

What issues was the previous function usage causing?
Not that I am against the change, just to understand 😄

[skrech]

Very good catch :) I even intend to leave this into its own commit when merging this.

It can't be seen from the diff of the PR but I tried very hard to actually start the Mix task from different current working directory (because Cypress doesn't run in the project root). And when specifying custom path to mix.exs, reading the file won't succeed because it can't find VERSION file in what happens to be the current directory. __DIR__ would work because it's bound to the location of the file being read, so very robust.

Unfortunately, specifying MIX_EXS and MIX_DEPS_PATH wasn't enough to make mix running from non-project-root succeed because it couldn't find mix.lock. That seems to be a bug, so I gave up.