As before: use `#sql_type` instead of `#type` in the tests. The `#type` is the
category -- string, integer, datetime -- but the `#sql_type` is the storage
specifics -- `TEXT`, `VARCHAR`, `BIGINT`, `DATE. Switch to the `#sql_type` so
we can be sure it's being stored correctly.

The 4 byte limit is starting to wrap around; some complaints are being seen
online, e.g.
https://stackoverflow.com/questions/34477248/rails-paperclip-rangeerror/47999887#47999887 .

Use `#sql_type` instead of `#type` in the tests. The `#type` is the category --
string, integer, datetime -- but the `#sql_type` is the storage specifics --
`TEXT`, `VARCHAR`, `BIGINT`, `DATE. Switch to the `#sql_type` so we can be sure
it's being stored correctly.

In an effort to avoid filling $TMPDIR with stray files, let's close all
Tempfiles after we are done with them. Additionally, add an around-filter to
each test in the integration suite to catch cases where we don't do this.

This exposes issues around re-processing a subset of our attached files: it
leaves Tempfiles around. Mark that test as skipped (with a detailed
explanation) because we cannot figure out how to make it work.

Related to #1326.

As described in #2118, `OpenURI::Meta#content_type` will return
`application/octet-stream` when no `content-type` header is set. Using
the original `meta` fixes this issue.

While using the Paperclip gem, we noticed during some ad-hoc testing
that if you do not supply an extension when uploading a file, Paperclip
effectively skipped it's spoofing check, which allowed potentially
dangerous files to slip through into your application.

This addresses that by moving the checks around a little bit and only
testing against the extension when there is one.

This validation was causing issue when there is no content_type column
in the database, as the content type of the attachment would be empty.
There should be no need to check attachment's validity because this
`#reprocess!` method is running internally on the server.

Fix #2078

Encountered an issue where the URI was returning header with
content-disposition where the filename value wasn't enclosed in the
double quotes. Turns out that this is a valid grammar according to
RFC6266. Also made the logic more robust to account for spaces and
uppercase letters.

e.g., the way google stores its user profile photos (from their oauth2 API)
https://lh3.googleusercontent.com/-aRHQV4YjnBM/AAAAAAAAAAI/AAAAAAAAAAo/ngSjy9-yR5c/photo.jpg

Since the support version is Ruby 2.0 or later, magic comment is unnecessary.

> The UTF-8 default encoding, which make many magic comments omissible

https://www.ruby-lang.org/en/news/2013/02/24/ruby-2-0-0-p0-is-released/

This cause to erease previous image when the id change to above
`999_999_999`, for example:

```
2.3.6 :010 > id
 => 1000602578
2.3.6 :011 > ("%09d".freeze % id).scan(/\d{3}/).join("/".freeze)
 => "100/060/257"
```

"key" is a reserved keyword in MariaDB, so the SQL statement fails.
Surrounding the keyword in backticks fixes the error.

* Add deprecation notice to README

Addresses new projects, existing projects, issues, and PRs.

So that the `file_system` option renders correctly on the docs

Closes https://github.com/thoughtbot/paperclip/issues/2253

Follow #2481

2254 coverage (#2395)

* f(x): default to Paperclip::ContentTypeDetector

* fix: failures

* spec: cover consecutive periods

* fix: hound

* fix: hound