Replace the clunky direct transaction SQL

* With ActiveRecord semantic equivalent
Use COPY FROM STDIN for hits import

* Does not require superuser
* Is surprisingly faster. For UKTI import (average of 8 runs, 10 taken,
  lowest and highest timings discarded):
   * 17.9s  when copying whole file in one buffer (File.open(...).read,
              this commit)
   * 18.26s for line-by-line (File.open(...).each, not committed)
   * 21.3s  for older, file-based approach
* ANALYZE removed after hits_staging COPY. Was not adding anything and was a
  cargo-cult leftover.
Be explicit about popular tag ordering

* COUNT first, then name
* Fixes intermittent failure where order was unknown and would push out
  tags with equal count
* Also, tighten up the criteria for "Then I should see popular tags" step. Now
  checks count as well as fuller list. We weren't testing what we thought we were!
Move the import hits transaction boundary

* Align it with the file (which is where it should have been)
* Don't let a single failing file make it necessary to re-import the world
Don't copy paths from hits staging > 2048 chars

* Silently discard paths over 2048 characters in length on import
* We have a hard limit of 2712 bytes as an index size for Postgres
  (1/3 the page buffer size)
* We have a limit of 1024 chars for hits.path in mySQL, but mySQL cheerfully
  truncates it
* Our limit for hits.path in Postgres is 2048 characters
* There are no more than 17 paths in our entire hits corpus (at time of commit)
  that exceed this, and of these, most are misdirected ASP.NET ViewState
Remove an obsolete rake task and tweak a description

Closes #394
Use single quotes for PG strings in migration

* PG uses double quotes as table/column signifiers
Rake task to benchmark import:hits

* Can accept an argument for number of runs (defaults to 5)
* Prints a summary for the timings of the runs (excludes setup)
* Clears ImportedHitsFile records and hits up to the final test file's
  date before each run
Move benchmark:import_hits to benchmark:hits:import

* More consistent with what we've done elsewhere
* Allows us to use the same benchmark:hits:all trick later
* Move the actual import to a Benchmark module. We can't have
  multiple top-level same-named constants in .rake files, as rake
  loads all files, not just the one we care about/are invoking.
Add a benchmark rake task for all hits, all time

* Default to Ofsted
* Doesn't really simulate the view portion (we'd need a full-on
  Poltergeist for that. Not sure how hard (or not) that is)
* We only care about Postgres timings at this stage
Generalise the :all_hits_all_time task to just :view

* Can then accept params, e.g.
   `rake benchmark:hits:view[hmrc,summary,last-30-days,10]` or
   `rake benchmark:hits:view[hmrc,redirects,all-time,10]`
   `rake benchmark:hits:view[ofsted,hits,all-time,10]`
* Given no params, defaults to Ofsted, all hits, all time
Tidy up the temporary assignment of PG settings

* Add Transition::Import::PostgreSQLSettings
* Allows a tidier temp boost to working memory when importing hits
Compromise hits indices to balance import performance

Compromise indices to make import/view hits work after discovery of
very bad index selection on 9.1 in Preview (blocking single hit file imports
on a single query taking > 20mins). This is an admission that
we don't know what's gone wrong in Preview but we know how to fix it.
Preview doesn't select the "bad" import index when it isn't there, and hits view
can use these two in concert.

We don't know that 9.1 caused this, because it wasn't happening in dev
on 9.1, so we're assuming an environmental difference. We don't know
whether that environmental difference will affect 9.3.x in the same way.
We should try reverting to the two 3/4-column index solution on 9.3.x
later by reverting or erasing this commit.

This is less than ideal because we know extra indices slows import down.
On the plus side it speeds up the viewing of hits (particularly for
summary/category) by around 100%.
Ensure db/schema at latest
Temporarily boost maintenance_work_mem

Not something we'd normally do, but our mySQL->Postgres conversion job has a
lot of indexing in following migrations. Make sure these are not choking
on lack of memory.

We'll also need to up this amount in the psql load job via PGOPTIONS.
Specify the ordering of the bulk add preview "first 20 mappings"

- The bulk add preview page shows the first 20 mappings, but the
  ordering wasn't set so potentially mappings /a, /b, /c could have
  ended up as /a, /c, /b in the preview. This fixes that bug by
  specifying the ordering as in
  https://github.com/alphagov/transition/blob/postgres-master/app/presenters/batch_preview_presenter.rb#L23.
Fix sort order on leaderboard

* Nulls were appearing first in the errors column
* Make them appear last
* That's it
Move data access to the controller

* index.html.erb was calling ActiveRecord directly
Remove ".0" from integer leaderboard numbers

* For some reason, Postgres gives us a floating point column for an integer sum.
  Be explicit that this is not supposed to be the case by casting to ::integer
  in the sum/count parts of the leaderboard query