[GT-95] Prepare for API credential management based on renewal time

[ghost]

Refactor existing last-use-time code and add prototype test as for #438

[gregcorbett]

I've tweaked this slightly to reflect that I want unrenewed API credentials to be deleted at a quicker cadence than inactive users. This is to prevent inactive users having API credentials.

[gregcorbett]

I was slightly surprised the tests passed - as I naively assumed "Well, the deletion of unrenewed credentials hasn't been implemented yet, so the test should fail".

But the logic is almost the same (and hence the logic is reused) as deleting unused credentials, so it makes sense that the tests pass 😄

[gregcorbett]

rebasing on latest dev

[gregcorbett]

Why is the PR picking up the commits from #209 following a rebase?

[gregcorbett]

Why is the PR picking up the commits from #209 following a rebase?

So Git (not GitHub) thinks the merge-base (best common ancestor) is fab7bd0, which is not the latest pull request merged into dev - hence picking up the commits from #209.

$ git merge-base api-renewal-test dev
fab7bd03aaa795062bacd254c495fe7f9115a7db

[gregcorbett]

So Git (not GitHub) thinks the merge-base (best common ancestor) is fab7bd0, which is not the latest pull request merged into dev - hence picking up the commits from #209.

Following this StackOverflow answer to try and resolve this: https://stackoverflow.com/a/70994400

$ git rebase --onto dev fab7bd03aaa795062bacd254c495fe7f9115a7db api-renewal-test
Successfully rebased and updated refs/heads/api-renewal-test.

$ git merge-base api-renewal-test dev
2790f307a10457acce4e4567916f5bdf31534544

2790f30 is the latest PR merged into dev, so yay!

A subsequent force push seems to have resolved the weirdness.

[rowan04]

lgtm :)