Fix trending aSPET inconsistency with old trending

[jowlee]

Description

Edge cases for trending version aSPET not matching ePWJD.
Two bugs:
1.) Previously we were getting the diff in days in python as follows:

    o = track["created_at"]
    K = datetime.now()
    w = parse(o)
    k = (K - w).days

which gets the total diff in days, seconds, milliseconds and we take the day part off it.
In the updated postgres version, we get the diff by running (now()::date - aip.created_at::date) which gets the actual dates and subtracts the day part of it ie. 09/25/2021 - 09/21/2021 => 4 days

The previous case takes into consideration elapsed time, so if 24 hours past it counts as a day while the postgres method only takes into consideration the date.
To fix this, the day diff is not calculated using EXTRACT(DAYS from now() - aip.created_at)

2.) When fetching tracks to cache into the top trending, the selected tracks to score are the top most played in that time range. The net multiplier was not used in selecting the tracks in the new mat view method.

Tests

Serval scripts were written to compare the results from the two trending methods

How will this change be monitored?

manually

[raymondjacobson]

oh yes, the net multiplier is good

[raymondjacobson]

do we need the net multiplier at all though? can we issue this request without a top listen subquery?

[raymondjacobson]

in line w/ the "one experiment" thing

[jowlee]

This top listen tracks with the net multiplier is strictly to keep the trending consistent with the current trending algorithm.
The current trending gets the top X (100* net_multiplier) tracks and scores / sorts those and then takes the top 100.
This new trending scheme with the DB track trending score does not need this at all. It was previously done as a heuristic to make it more performant, but we do it to keep the trending consistent.