Split out moderation backend

[dholms]

This pulls the moderation backend out of the appview & into it's own service.

Mod service:

• Basically a copy of the moderation service from within the appview
• a few basic implementation changes:
  • refactored methods to use Map instead of Record (which we did recently on the appview & is quite nice)
  • Added some new classes for wrangling the all of the "subjectType" typeswitches we were doing
  • run event reversal in a separate daemon
• larger architectural changes:
  • Goes out to the appview to hydrate in records (including profiles) and handles
  • We treat takedowns as "push events". We transactionally store them in push event tables & then the daemon routinely polls & attempts to push those out to downstream services (appview/PDS). It retries up to 10 times
  • For push events, the mod service uses a service jwt signed by it's own key (which is announced in it's did doc)

Appview

• removed all existing admin routes
• added simple routes for getting account info & getting/updating subject status (such as takedowns)
• added a new service jwt auth method for an appointed admin service. This functions like user auth to the appview but it validates that the issuer is a trusted DID
• auto-mod pushes all events out to ozone backend instead of tracking locally
  • cdn invalidation is no longer done by auto-mod, but is handled by the appview app instances when the takedown request comes through from ozone

PDS

• We previously got in some of the admin service auth stuff into the PDS, but there was a strange semantic where the audience was set to the DID of the account that the action was about. This is updated so that it uses the PDS's DID
• Proxies createReport to mod service now (instead of appview) & gives the PDS a config var for a trusted mod service & URL

Random other things that got wrapped up into this:

• auth verifier in appview (refactored the api to look like the PDS's & added in an "admin service" verifier
  • refactored some of the auth checks for viewing takedowns in application routes (like getProfile) to use a new parseCreds util
• moved appview test seeds to dev-env (for re-use in ozone)
  • it would be great to reuse the seeds in PDS as well, but there are some subtle differences between them that I didn't want to sort through righ tnow

[devinivy]

Should these be hard-required on the pds?