[feature] support canceling scheduled tasks, some federation API performance improvements

[NyaaaWhatsUpDoc]

Description

• wraps the scheduler to support easy job cancelling
• copies over more of the required, (+ some niceties) logic changes from the ./internal/ap subpkg
• copies over more of the required, (+ some niceties) from the ./internal/{federation,processing/workers} subpkgs
  • create status handling now entirely within fediapi handler (removes need for double Statusable->Status parsing)
  • supports create of multiple status objects
  • vastly reduces federatingDB.NewID() complexity

Checklist

• I/we have read the GoToSocial contribution guidelines.
• I/we have discussed the proposed changes already, either in an issue on the repository, or in the Matrix chat.
• I/we have performed a self-review of added code.
• I/we have written code that is legible and maintainable by others.
• I/we have commented the added code, particularly in hard-to-understand areas.
• I/we have made any necessary changes to documentation.
• I/we have added tests that cover new code.
• I/we have run tests and they pass locally with the changes.
• I/we have run go fmt ./... and golangci-lint run.

[tsmethurst]

Is this check still performed somewhere? I remember this being quite important to avoid seeing unwanted statuses (replies to blocked domains etc) in the timeline

[NyaaaWhatsUpDoc]

I'm not sure what you mean by check, as this is a dereference of status ancestors. Though it is something that will be handled by the DereferenceAnnounce function above, though I have just realized a quick tweak it might need now... I'll also add a note here explaining why we don't need to dereference ancestors, i.e. because it's handled within the DereferenceAnnounce() function.

[tsmethurst]

Right, sorry I wasn't very clear. What I meant was:

The below call to p.surface.timelineAndNotifyStatus will derive timelineability of the provided status, in part, from the visibility of the status's parent.

Previously, this call to p.federate.DereferenceStatusAncestors ensured that this status parent was set (if present) before the status gets passed into p.surface.timelineAndNotifyStatus, thus ensuring that it's not timelined if the parent is not visible for whatever reason.

By removing this synchronous call here to dereference the status's ancestors, you may be reintroducing a bug where statuses sometimes got timelined when they shouldn't (eg., the status is a boost of a reply to someone on a blocked domain).

[NyaaaWhatsUpDoc]

Ahhhh gotcha. Makes sense. Will fix it :)

[NyaaaWhatsUpDoc]

I updated our RefreshStatus() and GetStatusByURI() fucntions to handle status parent dereferencing synchronously in the cases where they're dereferencing a new status :)

[tsmethurst]

Looking good. Just not sure about the panicking!