Why:
* On wikis with lots of bot activity like Wikidata, there is a large
volume of edits which can potentially create an article-linked
notification. These notifications are now actually rarely sent
because they are disabled for bots (T318523). However, the event
record is always inserted into the database, with no reference to
it, bloating the database.
What:
* Do not unconditionally insert an event into the database when
Event::create is called. Pass it to downstream calls and have
it inserted when it's clear it will actually be needed (i.e.,
a notification is definitely going to be created).
* Pass the event's payload to the job queue instead of requiring
its ID. Introduce Event::newFromArray, which unlike ::loadFromRow
handles ::toDbArray values that haven't been inserted into
the database yet.
* Introduce Event::acquireId which ensures the event has been
inserted prior to returning its ID as well as it does not get
re-inserted.
Bug: T221258
Change-Id: I8b9a99a197d6af2845d85d9e35c6703640f70b91
Changes to the use statements done automatically via script
Addition of missing use statements done manually
Change-Id: Iad87245bf8082193be72f7e482f29e9f1bad11fc
The key must match what is specified in the constructor of the
EchoNotificationDeleteJob.
The job specify their name in the constructor through __CLASS__, which
means that with the class rename this key also needs to be updated.
Bug: T322342
Change-Id: Id1eebb0cc3ddcdabe31c5531cd32f032ed52a69c
