Occassionally unable to access Couch Per User databases, after they're created

So I think there's an issue with the Couch Per User feature on clustered databases with one node. I'm using CouchDB 2.3.0.

I suspect user databases are being created with "n ≈ n > (cluster.n = 1)", or something like that... They're not consistently writable just after creation at least.

Manually creating user databases, and then setting `_security` documents work consistently by comparison.

## Expected Behavior
When using the Couch Per User feature on a single node instance, it should be possible to write to a user database, as soon as (or not too long after) it's created.

## Current Behavior
Create a new user with `couch_peruser.enable == true`. When polling the associated `user_` database, I receive a 404 response, even though the database has been created.

I think it's related to this GitHub ticket - https://github.com/apache/couchdb/issues/603#issue-237129069 The difference between this issue and my own experience, is the fact that I've set the `cluster.n=1`, so any POST requests shouldn't need a quorum to determine availability.

I'm pretty sure this isn't a pure async issue, because if I extend the timeout to wait longer for the DB to be created, I still experience the same problem. I should also state, that this issue only happens intermittently.

## Possible Solution
¯\\\_(ツ)\_/¯... That said, with a cursory glance, this 'TODO' jumped out at me:
https://github.com/apache/couchdb/blob/103a0624f309ea0d796176a55eb5faea68f26047/src/couch_peruser/src/couch_peruser.erl#L298

## Steps to Reproduce (for bugs)
1. Create a single node CouchDB cluster
2. Set `couch_peruser.enable` to `true`
3. Create a new user (ideally, programmatically)
4. Attempt to access or write (`/{db}` GET or POST) to the automatically created `userdb_******`

Also helps to programatically retry the write/access function.
I make 5 calls to the endpoint, over the space of a 20 second interval in an attempt to negate any race conditions.

Example log error output:

```
[notice] 2018-12-30T00:18:28.028842Z couchdb@172.16.0.30 <0.8860.0> 4cf3f1a0e6 localhost:5984 127.0.0.1 admin POST /userdb-*** 404 ok 17
[debug] 2018-12-30T00:18:29.031705Z couchdb@172.16.0.30 <0.8872.0> 8f64a178af no record of user admin
[notice] 2018-12-30T00:18:29.032887Z couchdb@172.16.0.30 <0.8872.0> 8f64a178af localhost:5984 127.0.0.1 admin POST /userdb-**** 404 ok 2
[debug] 2018-12-30T00:18:31.036855Z couchdb@172.16.0.30 <0.9002.0> 6745f08438 no record of user admin
[notice] 2018-12-30T00:18:31.038036Z couchdb@172.16.0.30 <0.9002.0> 6745f08438 localhost:5984 127.0.0.1 admin POST /userdb-**** 404 ok 2
[debug] 2018-12-30T00:18:35.041849Z couchdb@172.16.0.30 <0.9086.0> c3579d0751 no record of user admin
[notice] 2018-12-30T00:18:35.047631Z couchdb@172.16.0.30 <0.9086.0> c3579d0751 localhost:5984 127.0.0.1 admin POST /userdb-**** 404 ok 6
[debug] 2018-12-30T00:18:43.054896Z couchdb@172.16.0.30 <0.9199.0> 6a15101a52 no record of user admin
[notice] 2018-12-30T00:18:43.056778Z couchdb@172.16.0.30 <0.9199.0> 6a15101a52 localhost:5984 127.0.0.1 admin POST /userdb-**** 404 ok 3
```

## Context
To generate user account 'buckets' on user creation.

## Your Environment
- Ubuntu (Trusty)
- Couch 2.3.0

Start with src/couch_peruser/src/couch_peruser.erl around the TODO at line 298, then reproduce the single-node setup with couch_peruser.enable enabled and retry access to the generated user database. Compare creation and access behavior against the reported 404 logs; done means a newly created user database can be read and written reliably.

Written by the indexing model from the issue text.