refactors
- fatcatd -> fatcat-api-server
- fatcat_api -> fatcat_api_schema (or spec? models? types?)
- standardize "mutating"/"edit" actions
    => have editgroup_id be a request-level param everywhere (not entity-level;
       for batch)
    => editgroup_id as query param
    => editor_id from auth (header)
- consistent "expand"/"stub" flags

correctness
- enforce "previous_rev" required in updates
- reread/review editgroup accept code
- enforce "no editing if editgroup accepted" behavior
- changelog sequence without gaps
- batch insert editgroup behavior; always a new editgroup?

edit lifecycle
- editgroup: state to track review status?
- per-edit extra JSON

account helper tool
- set admin bit
- create editors
- create keypairs
- generate tokens
- test/validate tokens


later:
- pure-rust "benchmark" scripts that hit, eg, lookups and batch endpoints
    => criterion.rs benchmarking
- try new actix/openapi3 codegen branch
- refactor logging; use slog
- test using hash indexes for some UUID column indexes, or at least sha1 and
  other hashes (abstracts, file lookups)

schema/api questions:
- url table (for files)
- get works/releases by creator
- "types"
- define release field stuff
- what should entity POST return? include both the entity and the edit?