raven/models/Feed: don't fetch 404 feeds

If feedparser gives us a 404 on a feed, just kill it, Jim.
raven/models/Feed: be less aggressive about fixing fast feeds

We haven't gotten this bit of logic completely right yet, so let's tune
it down for now. We'll come back later.
raven/settings: make multidb more flexible

In production, Readraven is setup thusly:


                             postgres streaming
     +--------------------+  replication        +---------------------+
     |                    +-------------------->|                     |
     |   rw postgres      |                     |    ro postgres      |
     |                    |                     |                     |
     |   celery workers   |                     |    nginx/uwsgi      |
     |                    |<--------------------+                     |
     +--------------------+   PUT user data     +---------------------+
            master                                 slave / front end


On all nodes, there is a local postgres running, defined with:
    DATABASE_URL='postgres://localhost...'

On a slave, you will also have:
    WRITEDB_URL='postgres://<ip of master>...'

We want the front end to read all data from localhost. But writes can
only go to the master (over the network). A front end with a web server
will receive http PUT as a user reads a feed and marks a FeedItem as read.
Those writes must go to the master.

Finally, the router is super simple:

class MasterSlaveRouter(object):
    def db_for_read(self, model, **hints):
        return 'default'

    def db_for_write(self, model, **hints):
        return 'writedb'

So now, some problems:

	1) for testing, on a local machine, no one wants to setup TWO dbs
	for testing. But if you don't have a 'writedb' defined, then the
	above router code chokes.

	2) in production, on the master, DATABASE_URL == WRITEDB_URL and
	then you get weird circular import problems.

The ugly solution is to conditionally define 'writedb' and conditionally
use the router *only* on a slave node, which we detect via an environment
variable.

Your dev machine doesn't define the envvar, and therefore will only have
a 'default' db. And in production, 'master' will also only have a default
db, ensuring both reads and writes just hit the local postgres. Any slave
nodes will learn about a new 'writedb' and they'll also get a router
that tells them how to use the django multidb setup.

Whew.
Merge pull request #12 from achiang/the_grind

feed fixes and multidb