fix: force mongodb connection to direct on localdev

[KenLSM]

Problem

On local dev, several BE APIs will fail with Server selection timed out after 30000 from MongoDB.

Solution

Add directConnection=true to force all db operations to one single host designated in the connection URI.

Background
The APIs failures were not completely deterministic, however some APIs fails much more constantly than other. APIs that never failed were POST requests, and specifically those that causes a DB write. While, those that failed consistently were APIs that were targeting read: secondary (while read: secondaryPreferred didn't fail).

Aside: Definitions

secondary
Operations read only from the secondary members of the set.

secondaryPreferred
Operations typically read data from secondary members of the replica set. If the replica set has only one single primary member and no other members, operations read data from the primary member.

---

The above explains the phenomenon of why it:

1. didn't fail on deployed environments (staging, uat, ...)
2. only certain APIs fail

---

Now what?
We have multiple approaches here:

1. Setup replicaSet on our localdev following the bitnami guide
2. Force directConnection such that all operations are routed to primary replica, even for those that specifically targets secondary
3. Update all secondary to secondaryPreferred

For option 1, it incurs 2x more memory consumption as each additional DB docker instance adds ~200MB, and we have to spin up the secondary + the arbiter (to co-ordinate leader election) node -- I've tried setting this up, but didn't manage to successfully find the correct configuration after a few hours.

For option 2, all traffic will be channeled to the singular DB on docker. This is chosen as it is the simplest fix while mimicking our prior local dev behaviour.

For option 3, it will cause some reads that we intend to only be on secondary to be channeled to the primary node. i.e., generation of document stats on the landing page which is non-mission critical.

[wanlingt]

lgtm, thanks for investigating this!