Move to a single worker model

[joshk]

This change moves from using a Dispatcher -> Worker model, to having Workers have multiple subscriptions to the builds queue but use SERIALIZABLE transactions and retries to ensure safety when updating Jobs and Build information.

This works similar to what we do with travis-logs, each process can run 1 or more subscribers, with the current default being 2.

This allows us to scale up hub processing on the fly by either increasing the number of subscribers per process, or more processes in general.

I have tested this on staging and things look good, but we might want to run some load through it to make sure the transactions are doing their job.

[joshk]

Already noticed a few jobs not having their state and information saved and propagated correctly

[joshk]

After removing the query cache things seems to be behaving correctly. I run a bit of load through this and I don't see any more jobs or builds where their state info isn't updated correctly.

[joshk]

The transaction code could probably be moved to the service. I'll be happy to do this once this PR is given the thumbs up.

[joshk]

And still not behaving correctly 😕

[joshk]

I'm pretty sure I have this working correctly!

I updated the UpdateJob service in core to use a SERIALIZABLE transaction, and a Postgres Advisory Lock around the build id.

The Advisory Lock works like an application mutex based on the lock id.

The Advisory Lock code is in core, but might be worth moving to support.

Before we can use this (if we decide to use this) I need to merge my core changes into master.

[joshk]

This is now ready for review.