enable management of environments with non-default configurations

[mykmelez]

There are currently three Rkv methods that create environments: new, with_capacity, and from_env. If one consumer opens an environment using Rkv::new (which uses the default capacity of 5 databases), and then a second consumer tries to open the same environment with Rkv::with_capacity(10), then the Manager's RwLock will serialize those calls, but what should the result of the second call be? If we return the cached environment, then we're returning an environment with a different capacity than the consumer requested.

At the moment, we actually avoid this problem, since Manager::get_or_create only accepts an Rkv::* callback that takes a single parameter, which means it only accepts Rkv::New, since Rkv::with_capacity and Rkv::from_env both take two parameters. But that actually raises a new issue: how do you use the Manager to protect an environment with a non-default configuration?

We should rethink the way we manage environments to enable managing environments with non-default configurations. In the process, we'll need to figure out what to return when a consumer tries to get_or_create an environment with a different configuration than an already-cached environment for the same path.

[ncloudioj]

Ah, I see what you mean.

Looks like Manager is missing a "delete (close)" method in the following cases:

• Be able to close the env on-demand if the consumer has finished the interaction with rkv, and won't need it thereafter. Closing a rkv env will free up certain resources, such as reader/writer slots in the lockfile, opened db handles etc
• If a customer wants to open the rkv env with a different configurations, an env close is required as all the mdb_env_set functions (max_readers/max_dbs/max_map_size) need to be called after mdb_env_create and before mdb_env_open

So if a reconfiguration is needed, the customer has to "delete" the env in the Manager at the appropriate point, and then re-open it with the new setup.