Refactor Source metrics

[mdoering]

Refactor Source metrics

[thomasstjerne]

The source metrics view is tightly connected to the metrics endpoint: https://api.dev.checklistbank.org/dataset/3/source/1010/metrics
If an issuesCount object is added to the endpoint (like on the import endpoint: https://api.dev.checklistbank.org/dataset/1010/import?limit=1), it will be trivial to have a view for that - might even show up automatically.

It is less obvious how the metadata view could be included. If we want it in the same table, there should be an object for that also in the metrics endpoint. Alternatively, it could be under a separate tab on the same page.

[mdoering]

I was hoping to retrieve separate data for different views instead of putting it all into the source metrics, but I'll see how easy / performant it is. I fear we slow down services while most people only use the default view.

[mdoering]

It is actually super simple to get the issues for the current public dataset into the source metrics - at no extra cost.
Keeping in mind we only want to show it for projects, I won't add it for releases.

[mdoering]

@thomasstjerne do you maybe remember why we keep a list of MD5s in the source metrics? It will have more than one entry if different sectors from the same source have syncs from different times, i.e. import files. Do we use that in the UI anywhere?

"latestMd5":"3D89239DEC0FCF8E2CC68C83AB4640B8",
"datasetMd5":[
"3D89239DEC0FCF8E2CC68C83AB4640B8",
],
"datasetAttempt":[
8,
],

[thomasstjerne]

Yes, the UI seems to use it to add an asterisk if the latest is not first in the list of datasetMd5s