Update recollection frequency

[ABrain7710]

Description
So the current issue is that repos are allowed to be recollected if they are more than a day old. This is causing issues in datasets where one user has the majority of the repos and there are many other users that have small amounts of repos. For example in a dataset where one user has 20000 repos and 19 other users all together have 2000 repos. In this case the single user with a lot of repos only has a 25% chance of being selected by the scheduling algorithm (in fact all users have a 25% chance). The issue is that the other 19 users have enough repos that there are always some repos that are more than 1 day old and therefore can be recollected. This results in the 20000 repos from the single user only being considered 25% of the time even if some of their repos are 3 months old, and the repos for the other 19 users are 1 day old. What is difficult about this issue, is that this is the expected behavior. Due to the fact that we don't want users that add a lot of repos and steal all the bandwidth. So to solve this I changed the requirement for recollection to 7 days for core, 10 days for secondary, 7 days for facade, and 10 days for ml. This means the repos for the 19 users will likely be processed through in a day or so, and then for the rest of the 6 days the older repos from the user with 20000 repos will be selected for collection every time since they are the only one left with valid repos to collect.

This PR fixes #

• Repos that were collected a day ago being collected before repos that haven't been collected in 3 months

Signed commits

• Yes, I signed my commits.