Integration tests need to start subprocesses that use the
same database as the test. This matters when running under
pantsbuild, because pants runs several instances of pytest
in parallel. We configured pants to pass an env var to
disambiguate parallel test runs: ST2TESTS_PARALLEL_SLOT.
Then, the db name gets suffixed with this slot number at
runtime. But, when an integration test runs production
code in a subprocess, the production code does not use--
and should not use--any ST2TESTS_* vars, meaning the
subprocess ends up using what is configured in the conf
file instead of the parallel-safe test db.

Thanks to a new-ish oslo_config feature, we can now
update config via env variables. So, make use of that
in integration tests to override the conf-file provided
values with test-provided values.

Integration tests need to start subprocesses that use the
same redis as the test. This matters when running under
pantsbuild, because pants runs several instances of pytest
in parallel. This PR prepares to add support, to disambiguate
test runs--similar to the database logic--using the env var:
ST2TESTS_PARALLEL_SLOT.
In any case, when an integration test runs production
code in a subprocess, the production code does not use--
and should not use--any ST2TESTS_* vars, meaning the
subprocess ends up using what is configured in the conf
file instead of the (planned) parallel-safe coordinator.

Thanks to a new-ish oslo_config feature, we can now
update config via env variables. So, make use of that
in integration tests to override the conf-file provided
values with test-provided values.

This is needed so that vars are initialized before
using them to configure the itest subprocesses
via env vars.

Integration tests need to start subprocesses that use the
same exchanges as the test. This matters when running under
pantsbuild, because pants runs several instances of pytest
in parallel. This PR prepares to add support, to disambiguate
test runs--similar to the database logic--using the env var:
ST2TESTS_PARALLEL_SLOT.
In any case, when an integration test runs production
code in a subprocess, the production code does not use--
and should not use--any ST2TESTS_* vars, meaning the
subprocess ends up using what is configured in the conf
file instead of the (planned) parallel-safe coordinator.

Thanks to a new-ish oslo_config feature, we can now
update config via env variables. So, make use of that
in integration tests to override the conf-file provided
values with test-provided values.

conf/st2.dev.conf already sets [coordination].url, so we do not
need to use sed to enable it again.

It looks like the st2.dev.conf change happened shortly after the
sed logic was added to prepare-integration.sh.

This will make it safer to run tests in parallel as the
tests will have separate service registration and coordination locks.
To do that, this adds a namespace= query param to the redis url
that includes the slot number that pants creates to allow tests to run in parallel more safely.
The namespace is used by the tooz library's redis driver as a prefix
for all the redis keys. Thus, multiple tests can use the same
redis database without clobbering each other's keys.

This, adds a new messaging.prefix option that gets modified
to include the test slot as needed.

Exchanges are defined as module level vars initialized on import.
But, oslo_config is not setup yet at import time, so delay applying the
new prefix setting until just before they get created in RabbitMQ.

Luckily, Exchange() objects are lightweight objects that just
hold the exchange name and type. They could do more, but we
don't bind them to a channel. Because the exchange objects
merely hold strings, and because they are basically singletons
(module-level vars), we can safely update the exchange name
just before declaring it in RabbitMQ. From that point on,
everything that uses a singleton exchange object will get
the updated name.

Now that the exchange name prefix is configurable, we have
to undo the prefix to maintain a backwards compatible API.
Also, having the event names vary based on config would be
a very bad UX, so we don't want to go there anyway.

Connection has a cache of which entities (exchange/queue)
have been declared, so this shouldn't have too much of a
performance impact. This does, however, make tests much more
reliable.

Only run them when ST2_CI==true to minimize requirements for local development.
Also fix a typo in a comment.

These changes were already made for MongoDB and RabbitMQ rules.
This removes a TODO comment and slightly refactors to follow the same convention.

pants `--tag=...` notes:
`--tags=abc,def` (a csv list):
    is an OR condition (either `abc` tag, or `def` tag, or both).
`--tags=abc --tag=def` (multiple entries):
    is an AND condition (Both `abc` tag AND `def` tag).

So, we use `--tag=integration --tag=-st2cluster` to select targets
that have the `integration` tag AND do NOT have the `st2cluster` tag.

pants `--tag=...` notes:
`--tags=abc,def` (a csv list):
    is an OR condition (either `abc` tag, or `def` tag, or both).
`--tags=abc --tag=def` (multiple entries):
    is an AND condition (Both `abc` tag AND `def` tag).

So, we use `--tag=integration --tag=st2cluster` to select targets
that have the `integration tag AND the `st2cluster` tag.
(The other integration test job excludes the st2cluster tagged targets).