Extend IDomainObjectModification

Currently the notify signal is sent before the database commit has occurred. It
is not possible to listen for modification events and know that the changes
have made it to the database. This can lead to a race condition if you try to
get a record from the database.

For an example see:

https://github.com/ckan/ckanext-archiver/issues/6

This extension of the interface would allow notification after the database
commit has occurred.
[#1879] Set DataStore to legacy mode when using PostgreSQL < 9.x

Up until now the user had to actively set legacy mode when running PG
8.x, and if not you could end up with the full datastore running on an
old postgres version. Features like the SQL search are not properly
supported on these versions, so we need to explicitly disable them when
running on PG 8.x, by setting `legacy_mode` to True.

The current behaviour is that legacy mode will be activated if
`ckan.datastore.read_url` is not present in the configuration and/or
postgres < 9.x.
[#1879] Fix tests

The travis setup explicitly removes the `ckan.datastore.read_url`
setting when running the tests, so we need to use a dummy one.

Also some refactoring
[#1917] Check only for active org memberships

When returning the list of organizations that a user belongs to return
only the organizations that they currently belong to - not orgs that
they were previously a member of.
[#1917] Add tests and docstring for organization_list_for_user()
[#1917] Add another organization_list_for_user() test
Add IResourceUpload plugin interface
Generalise IResourceUpload into IResourceModification

Instead of proliferating the interfaces with special resource
cases, by creating yet another resource interface for any resource
creation (not only uploads), IResourceModification incorporates
both uploads and links, but after_create (which replaces
after_upload) provides an additional parameter indicating whether
the resource was uploaded or not.

This entail renaming but also a slightly different workflow in
calling the interface since we must catch deletions before
creations.
Add comments to better explain the upload process

The upload process is slightly hard to follow and just by looking
at the code it looks like if one accidentally sets a filename and
then also sets clear on the ResourceUpload, it would remove the
just created file.

This is handled by javascript in the resource form which sets or
resets (to an empty string) the clear_upload input field which is
slightly disconnected to the upload function of ResourceUpload.

So, in order to make the code better stand on its own and to
further explain the assumption it makes about self.filename and
self.clear and how those work together, the upload function now
has some comments to guide developers and divert us from breaking
things.
Remove 'file uploaded' and 'file deleted' return values from uploader

These were added to the previous IResourceUpload to know if a file
was being uploaded or if an uploaded file was deleted.

Looking into the ckan extension "ckanext-datapackager", for which
the original ckan branch, "datapackager", was developed (which is
where IResourceUpload comes from), it turns out that the file
deletion trigger isn't used. So it is save to assume that no-one
uses it (since it's in a special branch) and it can therefore be
removed.

The 'file uploaded' trigger can be inferred from the resource
dictionary's key 'url_type' which has the value 'upload' when a
file has been uploaded, but is set to an empty string when the
resources just links to an external file. Therefore we do not need
to track file uploads via a special parameter. This also makes the
IResourceModification after_create method use in extensions easier
to in case someone adds a different url_type and wants to process
'upload', '', and their special type of url_type.

Also note that after uploading a file the upload method returns.
That's still a good idea from the IResourceUpload implementation
and is left in there because that makes it slightly clearer that
after uploading a file the method should never even get to the
self.clear check (since we do not remove files if we upload them
as explained in the comments).
Add after_update to IResourceModification for resource updates

In case extensions want to do different things based on creations
and updates, it is better to split them up into two different
methods.
Add pre-processor methods to IResourceModifications

Add before_(create,update,delete) to IResourceModification to
complement the existing after_(create,update,delete) methods.

This allows extensions to parse data before actually creating,
updating or deleting it. Since 'file deleted' was removed in a
previous commit as it wasn't used, it could still be useful. By
adding the pre-processors to resource updates, one can now infer
file deletion from the resource being passed into the before_create
and before_update since those include the magic 'clear_upload'
input which indicates whether a file will be deleted.
Update IResourceModification documentation

Minor edits to the documentation of IResourceModification methods
to make the documentation clearer.
Add call to before_delete and after_delete in IResourceModification

Until now before_delete and after_delete weren't being called when
a resource was deleted. They are now called in the appropriate
places but that required a change in the parameters passed in (for
the sake of performance).

The parameters sent to before_delete are context, resource and
resources where context is just the context dictionary, resource
is the data_dict being passed in (it should only contain the id
of the resource that should be deleted) and resources which is the
list of the package's resources.

The parameters sent to after_delete are the context dictionary
and the resources list (so not the resource dictionary) and the
resources list now does not contain the resource that was deleted
(after all, it was deleted).

This way we can still just use the list comprehension which is
faster than a for loop as we should not take a performance hit
for an edge case like this one (e.g. by switching to a for loop
or something).
Add test cases for the IResourceModification plugin interface

This adds one test case for each of the three sets of hooks:

* One test case for before_create and after_create
* One test case for before_update and after_update
* One test case for before_delete and after_delete
Revert "Add test cases for the IResourceModification plugin interface"

This reverts commit 9f034dcff42ffeccca63a8ec835897a184e1f4ea.

The commit added tests to the "old" version of tests which has now
been deprecated and new_tests should be used instead of it.
Add example plugin implementation and tests for IResourceModification

This adds an example ckan extension that uses the IResourceModification
plugin interface and then adds three tests for that example
implementation:

* One test case for before_create and after_create
* One test case for before_update and after_update
* One test case for before_delete and after_delete
Merge IResourceModification into IResourceController

This is done for consistency in the code (this makes it similar
to IPackageController).

It is worth noting that IResourceController already had a
before_show method which is called in the other methods as well
and some parameters could therefore be redundant but they are left
intact because it becomes difficult to know what is what if we ask
devs to use before_show in order to retrieve a variable they want
to use (and before_show can actually be called multiple times in
some cases).
Merge branch 'tryggvib-resource-modification-interface'
Merge branch '1917'