Custom Solr schema.xml file Closes #8

* The custom schema file defines the fields to be used for indexing
drops on the search server. This file is to be copied over to the target
Solr server instance
Solr search server integration

* Separate spring configuration file for the solr integration

*Use EmbeddedSolrServer for testing/dev environment. For production,
use HttpSolrServer i.e. connect to an external Solr instance

* Implemented searching the title and content of drops

* Add newly created drops to the search index as soon as they have
been posted to their respective containers (rivers, buckets). This is
effected in DropService#createDrops. Refs #9

* TODO: Implement search endpoint

* TODO: Exclude embedded solr server dependencies during packaging
Drops, buckets and river search

* Implemented searching (with pagination) of drops, buckets
and rivers. For drops, we first search the index then use the
IDs of the returned documents to fetch the drops from the DB.

* River and bucket searches are performed against the DB using the
LIKE comparison operator. Only publicly accessible buckets and/or
rivers are returned
Add search/ endpoint. Closes #7

* The search/ endpoint is exposed by the SearchController. It can be used
for searching buckets, rivers, users and drops. The supported search parameters
are: q - The search term
        type - Type of search (users, buckets, rivers, drops); drops is the default
        count - No. of results to return
        page - Search result page number

* Return a 404 if the search doesn't yield any result(s)
Resolve ${solr.server.url} placeholder in prod file

* Because of the multiple PropertyPlaceholderConfigurer beans - root-context.xml
and solr-context.xml - the ${solr.server.url} placeholder was not being resolved by
the bean in root-context.xml and as such the app was throwing an exception on startup.
This has been fixed by setting "ignoreUnresolvablePlaceholders" to true - in the property
configurer in root-context.xml
Remove private assets from search result

* For user search, remove the private rivers and buckets
that the user owns and/or is collaborating on.
Merge branch 'fix-dozer-mapping-config' into solr-search
Search endpoints for each resource

* Each of the 4 main resources; drops, rivers, buckets and accounts
have their own endpoint in the search controller. The basic parameters
(q, count and page) are the same for each of the endpoints.

* TODO Add date filtering for drops search
Background drop indexing

* Background drop indexing is performed via a scheduled
task that uses indexer.properties to fetch the drops that
are yet to be indexed

* TODO: Ensure background indexing doesn't clash with realtime
indexing - synchronize access to method that updates the ID of the
last drop to be indexed
Allow both max_id and since_id query params. Closes #1

* When querying river/bucket drops, the max_id parameter
was being ignored if the since_id parameter was present. The fix
allows both parameters to be applied when querying drops

* Single DropFilter class - Decoupled the DropFilter class from the River
and Bucket DAOs since the filter parameters are largely the same
Change drop indexing strategy

* Only use background indexing strategy to avoid complications involved in
setting the ID of the last drop to be indexed

* Added bucketId and riverId to the list of fields to be indexed. In this way, we
can perform full text search against a specific bucket/river.
DropDocumentRepository has methods to facilitate this.

* NOTE: Solr 4.0 has an issue with adding multiValued fields via the API. This
issue has been fixed in Solr 4.1 onwards.
See https://github.com/SpringSource/spring-data-solr/pull/1 for more details
Support multiple keyword search

* Where the "keywords" parameter in the bucket/river drop fetch
query contains multiple phrases/words (comma-delimited), generate a
Solr-specific query string (using Solr query predicates)  to be
used for the search.

* TODO: The order of ANDing the phrases matters. Fix this.
Use JNDI for the indexer properties

* The JNDI lookup retrieves the *location* of the indexer properties
file and the property keys used to retrieve the ID of the last drop to be
indexed and no. of drops to fetch when the indexer runs

* Use FileSytemResource instead of ClassPathResource to load
the indexer properties file
Use Quartz scheduler

* Replaced the Spring scheduler with the Quartz scheduler. Spring's
TaskScheduler doesn't always play nice in shared environments that use
Quartz

* Moved the scheduling bean to the
"com.ushahidi.swiftriver.core.scheduling" package

* Sample context configuration file for the API

* NOTE: Spring 3 is not yet compatible with Quartz 2+. Therefore
use Quartz 1.8.x
Set channel_id when adding new river drops

* Added entity mapping between a RiverDrop and Channel

* Update channel drop count when a river drop is deleted. We also now
check for permissions before removing a drop from a river

* Added mapping class mapping in the dozer configuration. When creating
new drops, the mapper did not now how to handle the "original_url" property.
This was not getting caught by the tests because this property was not
being specified

* Removed the "channel" column from TABLE "rivers_droplets"

* NOTE: This branch was created by branching off "solr-search"
* Closes #11
Validate the riverIds and channelIds drop properties

* For the drops to be submitted for posting to the DB, these
properties must be specified. Refs #1
Set id in ChannelUpdateNotification objects
Rectify exclusion of existing river drops

* The algorithm for excluding duplicate river drops was flawed
It appears Map is entries are not mutable. Therefore, for predictability,
remove entries and modify them then add them back (to the Map)

* Extended the length of the tag and tag_canonical columns to 100 chars
Fix river_channels drop_count update

* The parameter values for the drop_count update query were
wrong.

* Convert the channelDropCount to "long"  before incrementing.
Incrementing java.lang.Long objects has undesirable side effects
and as such, the drop_count for some channels was constantly at 0
despite the channel having drops in "rivers_droplets"
Accessor & mutator methods for dropCount

* The drop count for the river channels was not being
set so zero value was being sent to the client