"possibly expensive" turned out to be "actually expensive". On 'emu', with 1.5M
events, the counts take 85 and 154 ms for Project and Issue respectively;
bottlenecking our digestion to ~3 events/s.
Note: this is single-issue, single-project (presumably, the cost would be lower
for more spread-out cases)
Note on indexes: Event already has indexes for both Project & Issue (though as
the first item in a multi-column index). Without checking further: that appears
to not "magically solve counting".
This commit also optimizes the .count() on the issue-detail event list (via
Paginator).
This commit also slightly changes the value passed as `stored_event_count` to
be used for `get_random_irrelevance` to be the post-evication value. That won't
matter much in practice, but is slightly more correct IMHO.
As had been noted on some of the commands, 'ingest' was not the best place for
them. However, [project-level apps are not supported in
Django](https://forum.djangoproject.com/t/allow-project-to-have-management-commands/5220/2)
So just create a 'main' app. I want to qualify it as 'myproject-main' though, to avoid
further unqualified global namespace pollution. And I want to avoid prefixing with 'bugsink'
b/c that's annoying for tab-completion. So 'bs' it is.
I've moved all commands over; even though a case could be made that the "feeding" commands
(raise_exception, send_json, stress_test) are somewhat related to ingestion, that's not
a very good case :-)
in IMMEDIATE mode, project was passed from an (implicit) read transaction to
the immediate_atomic-wrapped code; this meant that it was possible to miscount
project.digested_event_count
* As per the spec 'takes precendence'
* Also fixes the reported bug on Laravel, which apparently doesn't send event_id
as part of the event payload.
* Fixes the envelope tests (they were doing nothing when I moved the
data samples around recently)
* Adds a 'no event_id in data, but yes in envelope' test to that test.
* Adds handling to send_json such that we can send envelopes when the event_id
is missing from the event data.
(I didn't think the effects on regressions through, but this will at least
manifest itself because you cannot mark an issue as "fixed in" a release
in which it occurs. It will also show up once we start displaying "events_at"
in the UI, which should be "soon")
* IssueStateManager.mute
* IssueStateManager.unmute (from Issue.unmute)
* more tests for alerts
* unmute moved to IssueStateManager
* create_unmute_issue_handler moved-over to models.py
