There's nothing they can be spoofing, and there's little danger of a
webserver accidentally sending a dangerous Content-Type with a file that
has no extension. If the browser chooses to interpret it in a dangerous
manner, no server-side library on earth can change that.

This isn't specifically related to RSpec, but is built off the branch
and is part of an effort to get the CI build green.

This is a big one.

This change converts all of the existing tests from test/unit to RSpec.
It's been a long time coming, and was specifically prompted by the
inability of minitest to work with Appraisal across the various Rails
versions. Instead of ironing out that headache, converting to RSpec was
preferable (after initial probing).

Many assertions are still assertions and are housed in the Assertions
module, but they should be converted as they get touched. Similarly,
since we're touching all the tests/specs, we convert all the hashes from
1.8 syntax to 1.9 syntax.

The `file` command on OS X takes the --mime-type option, which returns
only the type and not the optional encoding. This is nice, but it's not
portable. Use --mime and strip the encoding off if it's there.

And don't forget this time.

Validators love instances. Seriously, though, this was causing a problem
when the validator was being called and the private "send" didn't have
an instance to work on.

It resulted with downloading attachment (i.e. from S3) on each
instance validation even when attachment didn't change at all.

Allows a lambda to be passed to decide what format a style should
be processed as

There are some file types that the file command doesn't understand.
Notably, files that have a format, but are ASCII-text based (like ruby,
certificates, etc), show up as text/plain. This presents a problem,
because the mime-types gem either doesn't report them at all (as for
.pem files) or reports them differently (as for .rb files).

This change allows a Paperclip.options[:content_type_mapping] hash,
which allows for a mapping of { :pem => "text/plain" } which tells the
spoof detector that this is an OK matchup and to allow it.

It is now a requirement for attachments to do one of three things:
  1. Have a content_type validation (e.g. "image/*")
  2. Have a filename validation (e.g. *.png, *.gif)
  3. Explicitly *not* have one of those validations

The intent is to make the default more secure, and you have to
explicitly reject the security of a validation in order to not have one.

This option was added to `has_attached_file` some time ago, see https://github.com/thoughtbot/paperclip/commit/65e8d4f6de50732d8e1b.

AbstractAdapter wasn't delegating `binmode` or `binmode?` to the
underlying @tempfile object. `binmode` is useful for cases where the
Adapter object gets handed on to another library expecting an `IO`
object holding image data. We ran into this with Prawn and people using
`prawnto` in conjunction with Paperclip. Prawn wants to ensure the `IO`
is in binmode for embedding the image data.

Use hexdigest to ensure that tempfile names will be a reasonable length.  Remove illegal filename characters check since it is no longer relevant when doing a hexdigest on the filename

When using S3 for storage, their data consistency model makes the
current behaviour of Attachment#reprocess! unreliable.

Apparently, Amazon can not guarantee that PUT's called after DELETE's
is actually executed in that order.

Hence, I propose preserving files, when doing a reprocces.