Use a single connection pool across the whole application

[pietroalbini]

This PR changes how database connections are handled in the docs.rs application:

• Some code has been shuffled around, moving web::InjectExtensions to its own file and web::pool::Pool to db::pool::Pool.
• The configuration for the database is now stored in Config instead of being loaded from the environment each time a connection is created.
• The application is changed to create a single instance of Pool, which is created in the cratesfyi CLI and passed around. One result of this is that the frontend and the builds will use the same pool, instead of having the builds create standalone connections when needed.
• db::connect_db() is removed, forcing every connection to go through the database pool.

This PR is part of my refactorings to make buildtests feasible, and is best reviewed commit by commit. Unfortunately the last commit is quite big, but there was no way to split it.

[Nemo157]

How certain are we that the pool is fork-safe? (Given that we initialise it and pass it off to start_daemon which may then fork the process).

[pietroalbini]

Good point. I'd be tempted to just remove the forking code: we run docs.rs on production with systemd, and tbh everyone should just do that.

[Nemo157]

+1, I think self-backgrounding is an antipattern that can be dropped. Last I asked about it @jyn514 said it was used in production still, so might need a reconfiguration there to stop using it.

[pietroalbini]

Opened #844 to remove forking.

[jyn514]

How certain are we that the pool is fork-safe? (Given that we initialise it and pass it off to start_daemon which may then fork the process).

Technically all IO is unsafe unless it's been explicitly whitelisted:

   *  After  a  fork()  in  a multithreaded program, the child can safely call
     only async-signal-safe functions (see signal-safety(7)) until such  time
     as it calls execve(2).

[jyn514]

Mostly minor nits, overall this looks great :)

[Nemo157]

Technically all IO is unsafe unless it's been explicitly whitelisted:

I was more thinking that if the pool spawns a background thread to deal with closing old connections that thread won't make it across the fork.

[pietroalbini]

Replied to or addressed all review comments.

[jyn514]

Marking as P-high since it blocks #822.

[pietroalbini]

Rebased on top of the latest master and fixed the last concern in the last commit.

r? @jyn514