feat: Add assertMaxWriteQueries to test max queries against a table

[HazAT]

This PR adds a context method for unit tests to check against write queries on tables called: assertMaxWriteQueries

Usage:

class JavascriptIntegrationTest(TestCase):
    def test_adds_contexts_without_device(self):
        with self.assertWriteQueries({
            'sentry_projectoptions': 4,
            'sentry_project': 2,
            'sentry_grouptagkey': 12
        }):

This checks for UPDATE INSERT DELETE queries and counts how often they will be executed in a single unit test.
While this this approach is very basic, it would have caught the outlier in queries responsible for the latest outage.

See example:
If we re-add the line that was responsible for the outage again:

def get_option(self, *args, **kwargs):
        from sentry.models import ProjectOption
        self.update_rev_for_option() # <---------------------------------- this line
        return ProjectOption.objects.get_value(self, *args, **kwargs)

The test fails with:

======================================================== FAILURES =========================================================
_______________________________ JavascriptIntegrationTest.test_adds_contexts_without_device _______________________________
....
AssertionError: 22 write queries executed on `sentry_projectoptions`, expected <= 4
================================================ 1 failed in 2.92 seconds =================================================

This means in the future if someone introduces more "write" queries to the event ingestion, we would notice it upfront.

[mitsuhiko]

Instead of this use ast.literal_eval:

>>> import ast
>>> ast.literal_eval('u"Hello World!"')
u'Hello World!'

[mattrobenolt]

What’s wrong with just the builtin assertNumQueries? I get that this provides a bit more behavior, but seems a little overkill imo. I don’t think we typically care which tables, and read vs write usually. It’s just as easy to introduce a bunch of extra read queries that cause a similar incident.

[mitsuhiko]

@mattrobenolt easier to debug because you can see what the extra query is that was not expected before.

FWIW I did not make good experiences in the past with just query counting in tests as you typically just define a max and then refactoring just invalidates the point of it if they drop or caching changes some assumptions. I would almost like to fully sign off on all the queries but that seemed like a good middleground.

[mattrobenolt]

How does this work with JOINs and subqueries, etc? Which table are they counted against? All of them? One for each?

[mattrobenolt]

The only other comment I have with this is why explicitly only testing for write queries? What about read queries? I think these are all valid since it's more likely that we introduce unintended read queries.

[HazAT]

@mattrobenolt The library we use for parsing the query doesn't really work reliable for subqueries/joins to count the "reads".
https://github.com/andialbrecht/sqlparse

So we could invest more time to make it work by parsing the queries manually to correctly get the "read" count but not sure if we should really do this now.