Audit trail for more owner actions

[carols10cents]

Further steps beyond #1478. These changes wouldn't be exposed in the UI but would be in the database for us to use in determining who took what actions when.

• Add a column to the api_tokens table named revoked that's a BOOLEAN NOT NULL DEFAULT 'f'. Then instead of deleting tokens, mark them as revoked.

• Create a migration (using diesel migration generate, as explained in this guide) that adds a new table named version_owner_actions with the following columns:

  • id SERIAL PRIMARY KEY
  • version_id FOREIGN KEY REFERENCES versions (id)
  • owner_id FOREIGN KEY REFERENCES users (id)
  • owner_token_id FOREIGN KEY REFERENCES api_tokens (id)
  • action INTEGER NOT NULL (that would map to a Rust enum with variants publish, yank, unyank)
  • time TIMESTAMP NOT NULL DEFAULT now()

• Keep the headers[0] authorization header value accessible by holding onto it in the AuthenticationSource::ApiToken variant

• Within the crate publish transaction, after the new version record is created, create a new version owner action record with action = "publish", version_id = version.id, owner_id = user.id, owner_token = req.authentication_source() (and then extract the
  token value)

• Make similar changes to add records to the activity table in yank and unyank

• Add a field to EncodableVersion that's a Vec of all the actions, owner ids, and times that this version has had an action taken on it so that this info, minus the api token value, is returned in the API response

• Add a table crate_owners_actions that records who adds and removes other owners from a crate

• Add tests that this information is being recorded and returned as expected

[hinchley2018]

@carols10cents This sounds like a fun issue to sink my teeth into.
Would you mind if I pick this up?
Is there a deadline for completing this? (might take me a few weeks)

[carols10cents]

I don't mind at all, and no, there's no deadline!