Rename users clean or prune -- use aggregated user statistics

[DaedalusG]

This PR refactors use of the usageStatistics lastActiveUsage table which caused the command to timeout during execution on instances with a sufficiently large number of users. See #848

Instead the aggregated_user_statistics table is used via the site graphQL endpoint

query getInactiveUsers {
  site {
    users {
      nodes {
        id
        username
        email
        siteAdmin
        lastActiveAt
      }
    }
  }
}

This has two benefits

1. The backend to query lastActiveAt from the site graphQL endpoint is much more efficient than usageStatistics, and eliminates timeout concerns on many users instances
2. aggregated_user_statistics persists the date lastActiveAt eliminating the concern of null lastActiveUsage values which are misleading. lastActiveUsage is computed by reference to the event_logs table which only persists event entries for 93 days, when 93 days pass if a user had no entries in event_logs lastActiveUsage was set to null -- previously src users clean interpreted a null value as a user never having used the instance. A flag -remove-null-users is provided to remove null lastActiveAt` users

This PR also changes the name of the src users clean command renaming it to src users prune which follows the docker and kubectl cleanup command convention

Closes #848

Test plan

Tested on local machine

[erzhtor]

Besides, a comment regarding command (and flag) backward compatibility, PR looks good!

[erzhtor]

How are such command/API changes usually made in src cli? Should this be a major version increase or should we keep backward compatibility leaving both clean and prune commands and marking one deprecated?

[DaedalusG]

Almost all the functionality changes in terms of the command run locally, the old clean command had some big timeout issues see #848. The name change from clean to prune was mostly just a style change. I don't think this command is being widely used so I think the change is alright. To my knowledge no one has put this on a cronjob or anything like that yet.

[mrnugget]

How is this different than before in its performance characteristics? You're still fetching all users in the table, without doing any filtering. I don't see any improvement here?

[mrnugget]

Intendation is off

[DaedalusG]

This is hitting the aggregated_user_statistics table, and the value of lastActiveAt doesn't need to access the event_logs table the same way usageStatistics used to. Try it out here, its much more performant.

aggregated_user_statistics table is updating in the background, so this isn't accessing the event logs table at the time of the request.

[DaedalusG]

https://github.com/sourcegraph/src-cli/pull/903/files Indentation fix

[mrnugget]

Okay, so we're removing the N+1 error, got it.

That's only 1 of 2 possible performance issues, the other is that we transfer all users over the wire. (I don't think we want that on an instance with 10k+ users).

But I just checked and it turns out that the code here doesn't work: site { users } is paginated and only returns the first 100 users by default. You need to paginate through the results.

Here, run the query (note that I added totalCount), copy the output into result.json and then check with jq:

$ cat result.json | jq '.data.site.users.nodes | length'
100
$ cat result.json | jq '.data.site.users.totalCount'
208

that means you're only cleaning up the first 100 users.

[DaedalusG]

Ah, good catch @mrnugget will open a follow up on this to paginate and maybe implement a filter similar to what we were doing here: https://github.com/sourcegraph/sourcegraph/pull/43370