* Fix configuration
* Update Vault version
* Add config so a new release is published when a tag is pushed to Github

Integrate CircleCI to run test suites and build and push gems to Artifactory

As a tag could potentially originate from any commit, run the test suite
for any changes. They should pass prior to building and pushing a
released gem.

CircleCI should support tags

* Add git to publish-release in .circleci/config.yml for fix builds
* Fix indentation in .circleci/config.yml

Fix tag builds on CircleCI

Persisting Vault attributes on an `after_save` uses two separate queries:
one for the model `INSERT/UPDATE`, and another to `UPDATE` the ciphertext
for the encrypted attributes. Encrypting the attributes with a `before_save`
avoids the second query. In some cases users might _not_ want to have two
queries when saving a single record. This would be necessary for example,
when one has an auditing table and/or stored procedures that take some action
when a record is changed.

Persist attributes before save

Add serializers for Dates, Integers and Floats

What does this PR do?
---------------------
* Adds support for convergent encryption

Where should the reviewer start?
--------------------------------
* `lib/vault/rails.rb`
* `lib/vault/encrypted_model.rb`

Any background context you want to provide?
-------------------------------------------
* Vault supports convergent encryption since v0.6.1, but this gem
does not take advantage of this functionality.

Convergent encryption support

Only load the attributes that we need to when using vault_lazy_decrypt!

Improve lazy decrypt

Update README.md

Bump to v0.5.0

Rename gem to fc-vault-rails.

Remove Rails 4.1 dependency

…ecord

Replace Rails dependency with ActiveRecord

Bump to v0.6.0

If we've included vault-rails in an application that doesn't use rails but
only uses activerecord then we won't have access to
`Rails.application.config` to ask for `encoding`.  We wrap access to this
in some guard clauses.

Ideally we'd use the encoding on the database connection for the model, but
the `Vault::Rails.encrypt` and `Vault::Rails.decrypt` methods don't know
about models.  We could change these methods to take an optional encoding
parameter that the `Vault::Rails::EncryptedModel` will pass in from the
database connection.  However, we'd still need to work out a default for
the cases where we use these methods outside the context of a model, so
being more robust in the absence of a full rails application is good enough
for now.

We only rely on activerecord now, not the full rails gem so it makes sense
to use the `ActiveRecord::Base.logger` instead of attempting to use the
`Rails.logger` if rails is available.  We don't need to guard against
`ActiveRecord::Base` being defined though, as if it's not we'll have much
bigger problems than whether or not we can use the logger.

We also make the method and docs for it look more like the one we get from
`Vault::Rails.application` when it's not set.

If we can't rely on there being a full Rails app to get a default encoding
from, and we can't rely on the database connection for the models either
then it makes sense to allow setting an encoding explicitly for
Vault::Rails.  In most cases this will be excessive as we will be using it
in a rails app and can rely on that value, but for the few cases where we
can't this makes sense.  If the value is explicitly set we use that, if not
we fall back to the `Rails.application.config.encoding` value and if that
is not set (or not present because we're not in a rails app), we fall back
to a hardcoded default of UTF-8.

We've also made setting this value more robust by making sure that whatever
value is set is really a valid encoding.

…even-more

Decrease reliance on rails even more

Allow nil values in JSON serializer.

We need to create a git tag to do the actual release.

Bump to version 0.6.1

Bump lowest supported version of ActiveRecord and Rails.

* Update CircelCI config
* Use a docker image with RVM for CircleCI
* Use WWTD for running tests with multiple Ruby/Rails versions

Improve CircleCI Integration

Use Attribute API instead of instance variables for encrypted attributes.

Attribute API

Increase highest supported version of ActiveRecord to 5.2+ and < 6.0

Add attribute proxy for transition between plaintext and ciphertext fields

Bump to v0.7.0

Fix indentation in CircleCI config

…t-db

Mention how to setup the test db

We include the 0.6.2 and 0.6.3 changes from the 0.6.x branch and update
the 0.7.x description to mention the breaking changes from 0.6 to 0.7.

Update changelog for 0.7.x

We add the new rails gemfiles using the `appraisals` gem.  This means that
we can run `bundle exec appraisal rake` locally to run the specs against
rails 4.2, 5, 5.1, and 5.2.  We've also added these gemfiles to the
`.travis.yml` so these rails versions are added to the ruby version test
matrix that we run on CI.  Note that although we use CircleCI to run our
CI tests, we use the `wwtd` gem to read the `.travis.yml` config and do
what it would do.  This is confusing, but it works.

In rails 5.2 the behaviour of dirty tracking methods changed when they are
run during callbacks.  Methods like `<attribute>_changed?` and `changes`
do the same thing in callbacks run before save, but will behave differently
in callbacks run after save.  We'd already written
`__vault_encrypt_attribute` to understand this and use the
`saved_change_to_attribute?` method instead of `<attribute>_changed?`
method for rails 5.2.  Unfortunately, this is only the correct approach
when we're running `__vault_encrypt_attribute` in an `after_save` callback,
which we're not if we have run `vault_persist_before_save!`.  This means
`__vault_encrypte_attribute` is run in a `before_save` callback where the
`saved_change_to_attribute?` methods don't do what we want (because we
haven't saved any changes yet).  In this case we do want to use the old API
that the raisl < 5.2 branch uses.

We use `Person` in the "when not used" context because that model class
has not had `vault_persist_before_save!` called on it.  `EagerPerson` has
and that's why we use it in the "when used" context.  It'd be clearer if
we could explicitly call it in the spec, but there's no clean up option to
unset it so we need separate models.

…rails-5.2

Fix persist before save in rails 5.2

…ding

Improve loading of encrypted attributes.

Add methods for batch decryption and encryption

This means giving people a warning that `type` is meaningless on
`vault_attribute_proxy` now and they should move their type information to
the `vault_attribute` definition.  This also means reintroducing the
`Vault::AttributeProxy` module and having it do nothing but emit a
deprecation warning telling you to stop including it.

This also involves updating the gemfiles used by appraisal to run the
tests against multiple rails versions to get the new 0.7.1 version.

…ath-fixes

Prepare for 0.7.1 release

When we initially created version 0.7 of the gem to use the activerecord
attributes API, our goal was to create a unified version that worked with
rails 4.x and 5.x.  We ultimately failed in that because the attribute
API is private in rails 4.x and does not have the exact same behaviour as
it does in rails 5.x.  We decided that version 0.6 of the gem would support
rails 4.x and version 0.7 would support rails 5.x.  We didn't actually make
this choice explicit though, and so now we do.  This allows us to use rails
5.x features properly.

These might seem redundant, but we'll shortly be introducing the ability to
detect the serializer from the type, and these are both types that rails
provides by default for attributes so it makes sense to support them.

Our original strategy of looking for `ActiveRecord::Type::<the type>` works
for all the default rails types, but it doesn't allow us to make use of any
custom types that our database adapter might introduce.  In rails 5+
`ActiveRecord::Type.lookup` was introduced to let us find a type
implementation that has previously been registered.  This means we can use
the same set of types as our database columns, but also any custom types
that we might register ourselves (like a Money class or whatever).

This change is why we finally dropped support for rail 4.x as it does not
have this functionality so it's impossible to know what other custom types
are available at runtime.

For most cases, if we have specified a `type` option on `vault_attribute`
we will also need a serializer to deal with sending the value to vault as
a string, and converting it back again.  For most cases, we can also detect
the serializer based on the type and this means the author of the
`vault_attribute` definitions doesn't need to worry about it.

In postgresql there are inet and cidr types for columns that are handled by
the `ActiveRecord::ConnectionAdapters::PostgreSQL::OID::Cidr` and
`ActiveRecord::ConnectionAdapters::PostgreSQL::OID::Inet` type classes.
This means we get ruby `IPAddr` objects as the value for our attributes
when we read them out of the database with `ActiveRecord`.  We want to
support these column types out of the box so we've introduced a serializer
for `IPAddr` (based heavily on the implementation of the type class) and
set this serializer as the default for the `inet` and `cidr` types. We also
want to support `IPAddr` serialization for other column types that might
use `IPAddr` so we've also added it as the serializer for `ipaddr`, so that
other database adapters are not beholden to the names postgresql uses.

…-type-to-serializer-mappings

New inet type and automatic type to serializer mappings

Create v0.7.2

This is a cherry-pick and squash of the following commits from the 0.6
branch which add handling of blank values in the array of plaintexts and
handling of the entire array being full of blank values:

* f631432 - Handle blank values in batch
  encryption and decryption
* da08d60 - Batch encryption - handle
  arrays with only blank values

We squashed it because the second is really a bug fix of the first so it
makes sense to have a single fixed commit when we have that option.

Handle blank values in batch encryption and decryption

Bump to v0.7.3

.vault_persist_all and .vault_load_all are methods, that can be used for batch operations of several records.
.vault_load_all is useful only when in combination with lazy decryption.

Note that although this commit is forwardported from the 0.6 version we've
updated the implementation to work with the rails 5 attribute API we use in
0.7.

For both encryption and decryption we need the same initialization phase of reading the
configuration options. The idea is to avoid code repetition and cluttering even more code in EncryptedModel.

Note that although this commit is forwardported from the 0.6 version we've
updated the implementation to work with the rails 5 attribute API we use in
0.7.

…o-0.7

Add model level batch api to 0.7

Create v0.7.4

Only convergent attributes can be checked for uniqueness

Encrypting values is necessary not only in attribute setters, but also in the uniqueness
validator. In order to avoid duplication, the encryption is extracted in a separate method

You can search only by convergently encrypted attributes