Narrow the scope to load fewer objects

I believe this could load HostPath hashes for HostPaths on other sites, not
just the relevant one. It wouldn't have updated the Hits on those sites as
the Hits are scoped to the relevant site.
More efficiently update the related hits

Rather than fetching and instantiating each Hit that should be related to this
mapping, just send a single SQL UPDATE to update them all.
Update HostPaths, not just hits on Mapping create
Updating query_params causes refresh

When a site's significant query_params have changed, what a given Hit or
HostPath canonicalises to can change. This means that we might:
* show the wrong hits count for a mapping
* link to the wrong mapping from a hit
* not create new mappings from host_paths

Until now, we've ignored this problem. This change causes the relationship
between Mappings and HostPaths to be cleared and reconnected according to the
new canonicalisation rules. In turn, the connection to Hits is updated.
HitsMappingsRelations can be run for a single site

This will allow Site.update_hits_relations to only refresh the relevant
records, which will be particularly nice if many sites have their query_params
updated at once.
Only refresh relevant HitsMappingRelations

If several sites are being updated, this will drastically shorten running time.
Merge pull request #284 from alphagov/update_hits_relations_after_canonicalization_changes

Update hits relations after canonicalization changes
Stop duplicating status strings for SUPPORTED_STATUSES
Rename SUPPORTED_STATUSES to be http-specific
Add a 'type' column to the three mappings tables

This column stores the mapping type as a word string rather than as
an HTTP status code string. There isn't an appropriate HTTP status code
to use for unresolved mappings, so this is the cleanest way to store
users' decisions about mappings in the long run.

The new column has the same null constraints as the existing
http_status column on that table in each case.

This commit also adds validations for Mapping.type and sets the type
from http_status before validation. The type is not yet being set
correctly everywhere, but all the existing tests pass.
Set mapping type when importing from Redirector
Add a test to document import of '418' mappings

We currently have 198 mappings in production with an http_status of
418, which Redirector used for 'pending content', to signify that
content was coming but was not yet published, so couldn't yet be
redirected to. Bouncer serves 404 for these.
Only set type if http_status is supported

This means that the standard shoulda matcher for testing inclusion
validation works, because otherwise it wasn't able to set an invalid
value without it being changed by the callback before validation.
Add a one-off rake task to set type for existing mappings

This took 22 seconds to run in dev with 636,459 mappings
(replicated from production earlier this week).
Preserve '418' http_status as 'pending_content' type

This isn't a valid mapping type, but we already have 198 mappings
with http_status '418' in the production database because they
were imported from Redirector. We should not lose this information
about these mappings when switching to using the new type column.
Use type instead of http_status in Mapping model

This is a first step towards this goal, and will have broken lots
of things. The mapping model specs pass right now, though...
Make bulk tagger view model specs pass again
Make mappings batch model specs pass again

Now all model specs are passing.
Make mappings_from_host_paths specs pass again
Make Whitehall mappings import specs pass again