Update handle_config_terminate API

COUCHDB-3102

Add LICENSE file

Merge remote-tracking branch 'iilyak/2561-make-config-API-consistent'

This closes #1

COUCHDB-2561

Add vsn to implementaitions of config_listener

COUCHDB-2561

Don't restart event handler on termiation

COUCHDB-2561

Update config_listener behaviuor

COUCHDB-2561

fix warning

This dog won't hunt, no sir

set module version to 1

Fix monitoring when no parent is provided.

Will squash this down after review.

Implement option to provide a parent to monitor

The couch_event_listener_mfa already had the necessary logic for
monitoring the parent process that spawned it for a start_link usage. In
some instances we have rexi_worker process use the enter_loop style APIs
to avoid the need to spawn a separate process. This just adds an option
`{parent, pid()}` that allows these processes to specify the parent to
monitor.

Rearrange and lengthen the watchdog delay

I did not completely comprehend that code upgrades are not atomic for
all code. This watchdog ended up causing a node reboot into an unusable
state because it killed couch_db_update_notifier handlers before the new
code was installed for each app.

This lead to mem3 quickly cycling trying to use couch_db_update_notifier
which eventually took down the mem3 app which took down the node. Then
the node would reboot into 1202 after databases had upgraded their
headers which prevented the node from booting correctly.

By extending the timeout to five minutes and placing it before the first
call to terminating couch_db_update I hope to give the release enough
time to complete before telling each handler to upgrade.

Kill couch_db_event with supervisor functions

Apparently gen_event ignores unknown kill messages so we'll force a
clean shutdown with superisor functions.

Kill couch_db_event when it has installed handlers

This is to force the upgrade switch to the new couch_event application
force update notifications. Theoretically we could accomplish the same
thing with custom appups to forcefully remove couch_db_event from the
supervision tree but it turns out that's really hard.

Fix typo in the shutdown sequence

Fix compilation warning by sending not_registered

Fix callback spec arity

Use khash for tracking event listeners

After doing some testing locally it became apparent that ets is a bit of
a bottleneck when used as a bag with many duplicate keys. Theoretically
this new approach could be accomplished by nesting ets tables but the
ets table limit makes that approach untenable in the long run.

This just replaces the use of ets with khash as well as runs a nested
hash table structure to store the list of pids for each database name.

Add dependency on khash

Minor optimizations for couch_event_registry

Mostly making use of batch operations with match and multiple inserts. I
tried some more aggressive optimizations before these but those only
managed to make things slower. The major thing I tried was to use the
zero timeout trick to collect messages and then batch load those into
ets but that only managed to cause a large number of timeouts.

Add a event count metrics

Fix use of non-existant APIs

I must've been thinking I was going to add a stop function at some point
in the future. Rather than do that I just used the cast I added
previously.

Fix minor syntax errors and typos

Minor syntax error

Fix export definition for start_link/1

Fix use of proplists:get_value/2

It returns undefined when the key isn't found, not false.

Support db names specified as a list

I was being a bit conservative before in gathering database names to
listen to. This keeps all binaries and converts lists to binaries.
Anything that's not a list or binary throws an error.

Avoid use of undocumented functions

I'd copied this pattern from R14B01's gen_server. Apparently newer
Erlang's complain about it. I've updated to the version found in
R15B03-1.

Fix proplists:lookup/2 check

Apparently someone was smoking something strong when they designed the
API of the proplists module. lookup/2 returns none when a key isn't
found which does not at all match get_value/2 which returns undefined.

Fix the behaviour_info callback

Export the listen/4 function

Add OS process listeners

We don't use this in dbcore but if we ever merge this back to CouchDB
then we'll want to have this feature.

Fix callback module name for couch_event_registry

New couch_event:listen/4 API

This function doesn't return but allows a process to become an event
listener. Useful in RPC situations to avoid spawning an extra process
and doubling the message passing.

Add an API for the common case

Most of our current event listeners are single functions that don't
carry much state. Rather than force us to write a behavior module for
every one of these cases we can use this link_listener/4,
stop_listener/1 API to handle this common pattern.

Under the covers this just wraps couch_event_listener rather thinly to
give us the single callback export version of listening for events.

Make sure and exit with the reason given

Fix start/start_link return values

Add a cast API for couch_event_listener

Abandon the gen_server "inheritance" approach

There's not much benefit since these things aren't currently in the
supervision tree and the code in fabric_db_update_listener makes things
even more difficult for starting gen_servers.

I did contemplate having fabric_db_udpate_listener make use of
gen_server:enter_loop/N but rexi doesn't use proc_lib to start processes
and I don't have the desire to find out how much overhead that would add
to rexi_server.

Add an API to register for multiple DbNames

Just a convenience thing for code that may want to listen to more than
one database's update notifications.

Minimize message from monitors

I wasn't deduping monitors before. That bugged me enough to add an extra
ets table so that we can dedupe those messages and avoid the extra work
done by couch_event_registry.

Initial implementation

There are a few places we could be more efficient in managing the ets
table for event listeners but this simple approach should be able to
give us a rough idea on how fast we can pump messages through this sort
of design.

Initial commit