Creating a default user in JanusGraphAbstractAuthenticator should be safe for race conditions and eventual consistency

Nobody has claimed this yet.

Right now `JanusGraphAbstractAuthenticator` creates a new default user if it doesn't exist already. Here the code:
https://github.com/JanusGraph/janusgraph/blob/968cf4dc8ea944a43dc28f0c567bec2b0a049d9e/janusgraph-server/src/main/java/org/janusgraph/graphdb/tinkerpop/gremlin/server/auth/JanusGraphAbstractAuthenticator.java#L119

But the code isn't safe for race conditions and eventual consistency.
1. We could use eventual consistent storage backend. That is why `userExists(defaultUser)` doesn't guarantee that the user exists or not exists. For example, if we use Cassandra with small consistency level or with multi data center setup and we start multiple instances together then this method isn't sufficient (unless it uses some locking mechanism).
2. Again, even if we use one DC with big consistency level there is a small time gap between `userExists(...)` and `createUser(...)` which may be enough to execute `userExists(...)` two times and return `false`.

I.e. it is possible to create multiple users with the same name.

We should either prevent creating multiple users with the same name (i.e. by using locks or other mechanisms) or add logic to deal with multiple same users (i.e. either remove duplicates or ignore them).

Start in janusgraph-server/src/main/java/org/janusgraph/graphdb/tinkerpop/gremlin/server/auth/JanusGraphAbstractAuthenticator.java at the default-user creation around line 119. Read how userExists(defaultUser) and createUser(defaultUser) interact, especially with Cassandra eventual consistency and concurrent instances. Done means duplicate default users are prevented or safely handled, with the chosen behavior verified against the race condition described.

Written by the indexing model from the issue text.