Fix: correct count in the new tree listing

[MarceloRobert]

Changes

• Alters the behavior of the treeListing db table to store every commit of every tree. This is done so that we can keep the counts of older checkouts since we can receive multiple checkouts to the same commit in any order.
• Fixes problems with trees that have null values by setting nulls as equals and having better null comparison.

How to test

• Clear the database (docker compose down -v),
• Recreate it (docker compose up -d dashboard_db --build),
• Apply the migrations (poetry run python3 manage.py migrate),
• Retrieve the submissions and place them in a folder for consumption (submissions here),
• Also have the trees_name file (here) and place it in backend/volume_data/trees-name.yaml,
• Consume the submissions (poetry run python3 manage.py monitor_submissions --spool-dir folder/containing/the/submissions --trees-file volume_data/trees-name.yaml),
• Stop consuming when it reaches 0 files in the spool,
• Run the processing of pending tests/builds (poetry run python3 manage.py process_pending_aggregations), the processing finishes when everything is consumed,
• Run a query to update the start_time of the submissions (query here),
• Run backend and frontend, enter the treeListing to see the old result,
• Perform a select on the tree_listing table with the same time filter and origin, compare the results.

Known differences

There are still some differences between the new tree listing and the old one. Mainly is the fact that the new treeListing is able to show trees that have null git_repository_url, meaning that - with the provided submissions - there will be 2 more trees in the redhat origin.

Also, in the linaro origin there's an extra tree that seems to have 0 counts but also may be just a different version (different tree_name/url) of the mainline tree, which may have been changed when the data is consumed in the ingester. Since this is an extra tree, there's no effect on the old treeListing counts.

Closes #1703

[AmadeusK525]

This shouldn't be done here, it should be done at the table level by setting NULLS NOT DISTINCT to true

[MarceloRobert]

NULLS NOT DISTINCT only work at constraint checking level, but when I do this comparison in the query, it considers each comparison as a separate value, and so will consider NULLs as different values. It also doesn't matter if I try to make a comparison between a tuple of those values, the nulls will still not be equal, I tested.

https://www.postgresql.org/docs/current/indexes-unique.html
http://thoughts.davisjeff.com/2009/08/02/what-is-the-deal-with-nulls/

[gustavobtflores]

LGTM