Update `/api/stats` endpoint to return additional metrics data

[eecavanna]

Tasks

• [ ] Determine what the database queries were that people ran manually in order to provide metrics data to the leadership team for a recent report. At least some of the data pertained to downloads. I want to know what the queries are, anyway, so that I can run them in the future and so that people can consider them when interpreting the metrics data.
• [ ] Assess implications of running those queries "on demand" when a client visits the /api/stats endpoint. Some of the queries might take too long to run in "real time" like that. As an alternative, some of the queries could be run on a schedule and their results could be stored in the database, so that the API endpoint can serve them without actually performing the full query at that time (it would just fetch the pre-baked result of that full query).
• [ ] Either add the data to the response of the /api/stats endpoint; or create a private counterpart to the endpoint (e.g. /api/admin-stats) that returns that additional data.

Note: The assessment (second task) may result in us deciding not to pursue the implementation (third task).

---

Current behavior

For reference, here's what the /api/stats endpoint returns today:

{
  "studies": 28,
  "locations": 33,
  "habitats": 37,
  "data_size": 77352654942449,
  "metagenomes": 2927,
  "metatranscriptomes": 111,
  "proteomics": 52,
  "metabolomics": 34,
  "lipodomics": 0,
  "organic_matter_characterization": 2767
}

[eecavanna]

Here's the SQL query we submit to the Postgres database in order to get the number of user accounts that exist:

SELECT count(*)
FROM (
    SELECT DISTINCT(orcid)
    FROM user_logins
) as distinct_orcids;

-- Note: That happens to produce the same result as... 
--   SELECT count(*)
--   FROM user_logins;