Use read-only users in integration tests where possible

[AlekSi]

We should use a read-only user in integration tests where we can. For example, query (SELECT / find) tests do not change data and could run all queries in parallel; a read-only user will ensure that it is safe.

The implementation is not trivial because that will require changes in how we set up listeners. We should use a normal user when we insert data, then stop the first listener and start a second one with a read-only user.

Tigris is not in the scope unless they have already implemented authentication and authorization.

See references to this issue in code.

DoD:

• Change tests' setup (for both compat and regular tests)
• Change at least one test to use a read-only user

Notes:

• Changing all the tests is not in the scope of the task. If needed, please create a separate task for it.

[rumyantseva]

Reasoning: we want to make tests faster

[rumyantseva]

@AlekSi why do we think that having a separate read-only user would make tests faster?

[AlekSi]

Reasoning: we want to make tests faster

That's not accurate.

why do we think that having a separate read-only user would make tests faster?

We do not think so.

For example, query (SELECT / find) tests do not change data and could run all queries in parallel; a read-only user will ensure that it is safe.
See references to this issue in code.

Those tests are already fast; we should make them safe now