This refactor was born out of the inter-dependency cycles developing
between the "background" module and just about every other module which
was caused by the background module becoming a dependency of every
module that needed to background work and the fact that the background
module was also supposedly responsible for the logic for processing
those tasks.
Instead the "background" module is now very, very shallow and relies
entirely on the Postgres NOTIFY logic for triggering jobs. There's a new
table, `job` which holds just a type and single row ID.
All told, this means that jobs can be added to the queue as part of the
API-level or platform-level transaction, ensuring atomicity, and
processing coordination is handled by the platform module, which can
depend on anything.
This is extremely useful for testing.
In order to do this I needed to actually deploy the migration to a bob
fork so I could start to add support for behaviors I really want.
Specifically the ability to search for ids in a slice.
This requires a bunch of changes since the types on these tables are
much closer to the underlying types of the Fieldseeker data we are
getting back from the API.
I now need to use proper UUID types everywhere, which means I had to
modify the bob gen config to consistently use google UUID, my UUID
library of choice.
I also had to add the organization_id to all the fieldseeker tables
since we rely on them existing for some of our compound queries.
There were some changes to the API type signatures to get things to
build. I may yet regret those.
