Remove pulls trigger

[nora-codecov]

Part of the quest to reduce locks by eliminating triggers https://github.com/codecov/internal-issues/issues/1029

The trigger is deleted by these changes. The behavior is replaced in a cron job on worker codecov/worker#947.

What the trigger did: every time a pull was updated, if it was transitioning from OPEN to any other state, it set the flare field to null.
flare is an Archive field, so the value is either in _flare on the object or in our Archive storage.

Replacement behavior: see FlareCleanupTask codecov/worker#947
Once the trigger is removed, when the pull transitions from OPEN to any other state, leave flare alone in order to reduce locks and wait time.
The cron job runs overnight, gets all pulls that are non-OPEN and have flare (either in our db or in Archive storage), clears it (either in our db or in Archive storage) so flare is null.

more about flare:

• see Flare: what is it good for - absolutely nothing? codecov-api#999 and my summary of the findings in https://github.com/codecov/internal-issues/issues/1029

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.97%. Comparing base (7935e52) to head (9da9d82).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #450      +/-   ##
==========================================
- Coverage   90.58%   89.97%   -0.61%     
==========================================
  Files         401      324      -77     
  Lines       12509     9199    -3310     
  Branches     2103     1633     -470     
==========================================
- Hits        11331     8277    -3054     
+ Misses       1069      859     -210     
+ Partials      109       63      -46     

Flag	Coverage Δ
shared-docker-uploader	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Swatinem]

I’m unsure related to the should_write_to_storage changes. I don’t think those are needed necessarily?

[Swatinem]

this would rather mean that the flare is being stored in the JSON field of the table.
I’m unsure what would happen if you change this value based on the state. will is copy over data from storage to the database? or will that only happen if you save a new value in the field?

[nora-codecov]

good call - I think I was thinking that if this came back False it wouldn't be saved anywhere, but you're right, this would just force it onto the db field. Removing.

[nora-codecov]

This default value is dangerous and unnecessary. fixed the occurrences I found across the project.

[nora-codecov]

Making ArchiveService dependent on a repository was complicating my flare cleanup task.
It seems like repository is only needed to make the hash for reading and writing to the archive - you don't need it to delete.
To make my flare cleanup task much lighter, I removed the requirement for a repository in order to use ArchiveService. I added checks to the ArchiveStorage functions where the hash is used, so that you can't do something like write to storage without a hash.