optionally use alternate db connection for orm stuff (users/roles)

[melange396]

on the live system, the prod api servers are used when creating new users -- either via the admin page, or when users register at our google form (which just posts to another admin url). users are added by the api servers as records in the api_user table and their roles are stored in the associated user_role_link table (and the role names themselves are stored in the user_role table, but it isnt updated very frequently). HOWEVER, the prod api servers use the prod db replicas, and the prod db replicas are set up to mirror any changes made to the prod master db. so if the api servers are creating/updating users on replicas, the user tables on the replicas will soon be out of sync with each other and the master 😞

this change lets us (optionally) use an alternate db connection for the users/roles stuff. that way, we can have the prod api servers using the [distributed, loadbalanced, whatevs] db replicas for large epidata queries, but they can all use the master for user operations, eliminating the sync issues.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[krivard]

seems legit.

noting here that this will direct all user activity to primary, both reads and writes, but maybe that's an okay stopgap?

[korlaxxalrok]

Looks good 👍

[melange396]

yes, it will indeed direct all reads and writes to the master db. this is not intended to be permanent, but it allows us to continue with the api keys deployment.