The only rest API endpoint that uses sql queries is
/api/tenant/{tenant}/builds. There's no connection in there, which
means it doesn't make sense for that to be attached to a sql connection
(which is currently the case). Moreover, it doesn't make sense for
*every* tenant's endpoint to be attached to the *same* connection.
In other words, the current situation only allows for a single sql
connection system-wide, even if someone is using different connections
per tenant.
Moving the handler for the endpoint into the sql driver means that it
can dispatch the query to the appropriate connection for a given tenant
(since a tenant is always implied by the REST endpoint).
Moreover, the *rest* of the system actually allows multiple connections
within a single tenant, and we should support that here, but I don't
immediately have a solution of how to handle pagination across queries
that span multiple connections. This is an improvement in that it is
now tenant-scoped, but it's not ideal.
This also removes the (undocumented!) sql_connection_name config file
option.
It also uses the tenant name from the path to constructe the query so
that it always includes the correct tenant (this eliminates the
inadvertant ability for one tenant to query another tenant's builds).
The internal API here isn't great, but it will get cleaned up in the
next patch which converts to cherrypy.
Change-Id: Ie1f19f0b392d4c010ef43dc6220ff1c8667f5a4a
46e48d7b97