Sometimes, for whatever reason, a user might have more peers than their slot limit. This occurs because we don't ensure every user completes every download they start. This means a user could stop a torrent, clear the slot, and start a new one, and then resume the first one using peers cached by the client. When a user did this, the peer that was stopped would no longer be shown by the tracker and stats weren't affected. When the user completed the torrent, they got a error saying they couldn't send a completed event without first sending a started event. This could only be resolved by restarting the client or pausing/resuming the torrent which would reset the stats for that torrent session. This PR accounts for this fact and will allow peers updates to continue, but the user will no longer be able to receive peers in the peer list, and other users won't receive their peer in the list.
Now that we upsert history records without first selecting them, we can't rely on storing a peer's last uploaded/downloaded values in the history record to determine the user's uploaded/downloaded delta between the last announce. If a user has internet issues for a brief period of time but their client continues working, then their change of upload/download between the two announces needs to be kept track of. This is usually kept track of in the peer record, but if the peer is deleted after 2 hours of not announcing, then their last uploaded/downloaded data is deleted with it. We previously stored this data in the history table to handle such cases but this became erroneous if the user had multiple peers on a torrent. This new solution keeps the peers in the database for 2 days before concluding that the peer isn't coming back and deletes the peer permanently. After which point, a new peer will be created and an assumption is made that they uploaded/downloaded 0 data within their downtime.
Mark peers for deletion via this column so that they can be mass deleted later. This allows for combining peer inserts, updates and deletions into a single bulk peer upsert queue. Otherwise, when a user stops and starts a torrent before the bulk peer updates are collected in the queue, the peer may be deleted immediately after it gets inserted.
- github action updated with new ruleset in pint.json
- codebase linted with new ruleset
- contributors can now run `./vendor/bin/pint`
- action workflow will auto correct any lint issues upon commit/opened pull request
