Investigate if it is feasible to support a creation of a database with security object.

It would be nice to be able to set security at db creation time, atomically if possible.

## Expected Behaviour
I should be able to pass a security object as an option in `fabric:create_db/2` call and expect to get a new database with security set or reject on invalid or outdated security object.

## Current Behaviour
Right now we are either creating databases with an anonymous access or with a default security, based on value of "default_security" configuration.

## Possible Solution
It's not that hard to pass security object and use `default_security_object` as a default if it is missing. Most tricky part here are in-betweens, e.g. scenario where a db user in sec object got deleted or out of sync on different nodes so shards will be created on once node and rejected on another. As long as we don't have consistent CP user db (cassim) this is one murky area.

Start by tracing the `fabric:create_db/2` entry point and the `default_security` and `default_security_object` configuration paths. Investigate how security objects are validated and propagated during database creation, including the failure cases described for deleted users and inconsistent nodes. Done means the project has a decided, atomic behavior and documented implementation scope.

Written by the indexing model from the issue text.