This improves reliability because that time isn't charged to the test,
and also speeds up the test.

- For export_all warnings: either replace with explicit exports, add
nowarn_export_all compiler directives when appropriate, or in the case
of couch_epi_sup, move the test to dedicated test file and export the
function needed for testing.

- For "function already exported" warning in couch_key_tree_prop_tests,
remove include_lib attribute for eunit.hrl since it already gets
imported in triq.hrl

Previously there were quite a few problems with load_validation_funs
in the case when clustered database is deleted.

- the calls to load_validation_funs were failing with `internal_server` error [1]
- the deleted database stayed opened because:
  - the caller of the load_validation_funs (update_doc) stayed alive
  - the main_pid of the deleted database wasn't killed either
- there was an infinite loop in ddoc_cache_entry trying to recover ddoc from deleted database

The solution is:
- do not call `recover` for deleted database
- close `main_pid`
- use `erlang:error` to crash the caller

[1] - The stack trace was:
```
{database_does_not_exist,[
    {mem3_shards,load_shards_from_db,"bailey/meta",[
        {file,"src/mem3_shards.erl"},{line,394}]},
    {mem3_shards,load_shards_from_disk,1,[
        {file,"src/mem3_shards.erl"},{line,369}]},
    {mem3_shards,for_db,2,[
        {file,"src/mem3_shards.erl"},{line,54}]},
    {fabric_view_all_docs,go,5,[
        {file,"src/fabric_view_all_docs.erl"},{line,24}]},
    {ddoc_cache_entry_validation_funs,recover,1,[
        {file,"src/ddoc_cache_entry_validation_funs.erl"},{line,33}]},
    {ddoc_cache_entry,do_open,1,[
        {file,"src/ddoc_cache_entry.erl"},{line,294}]}]}
```

Use erlang release version to decide if the newer `rand` module is present or
not.

`erlang:function_exported(rand, uniform, 0)` could not be used here as it
returns false when function isn't loaded, even if module and function are both
available.

Replaced with crypto:strong_rand_bytes

There were a couple issues with the previous ddoc_cache implementation
that made it possible to tip over the ddoc_cache_opener process. First,
there were a lot of messages flowing through a single gen_server. And
second, the cache relied on periodically evicting entries to ensure
proper behavior in not caching an entry forever after it had changed on
disk.

The new version makes two important changes. First, entries now have an
associated process that manages the cache entry. This process will
periodically refresh the entry and if the entry has changed or no longer
exists the process will remove its entry from cache.

The second major change is that the cache entry process directly mutates
the related ets table entries so that our performance is not dependent
on the speed of ets table mutations. Using a custom entry that does no
work the cache can now sustain roughly one million operations a second
with a twenty thousand clients fighting over a cache limited to one
thousand items. In production this means that cache performance will
likely be rate limited by other factors like loading design documents
from disk.