Fixed JSON for deployments in pools#index(pretty view) - rev.

This patch is fixing failing tests on travis-cl. Cuke fails were
caused by previous patch
(commit msg c3b1d79b729d01fa0b91455510466f3871247b29) and
they appeared only when cukes runs on bundled gems.

Signed-off-by: Jiri Stransky <jstransk@redhat.com>
RM3772: Fix PoolsController spec for upstream

When creating an instance of Aeolus::Conductor::API::Error, we should
pass a string. PoolsController used to pass an array of strings. On 1.8.7
stack with Rails 3.0, the array gets merged somehow automagically when
rendering the exception template, but on upstream stack it has to be done
manually.
RM3762, RM3763: Fix PoolsController upstream

The spec used to generate request params with pool family association like
this:
`:pool_family => <instance of PoolFamily>`

But the request params should (and now does) actually look like this:
`:pool_family_id => <Integer (id of some PoolFamily)>`

On 1.8.7 + Rails 3.0 stack this got automagically corrected, on the current
upstream stack it does not.

This commit fixes RM3762, RM3763.
RM3771: Fix InstanceObserver spec for upstream

We need to test for deletion of a record, but ActiveRecord 3.2 does not
like when #reload is called on a deleted record.

With the spec in question, we can just #reload the parent record and
assert for the same thing.
RM3770: Fix Instance spec for upstream

There's no need to use FactoryGirl's `create` method in this spec, it
will test the code in question even if `build` is used.

Why the spec used to fail on upstream stack:

The `cloud_account` can be only built, not created, because the generic
`:provider_account` factory is just a stub factory meant for extending.
It doesn't assign some required attributes of ProviderAccount (e.g.
`username`), so the record cannot be saved. The F16 stack doesn't
consider this a problem when calling `create(:instance,
:provider_account => cloud_account)`, but upstream stack does.
RM3765, RM3769: hard delete with acts_as_paranoid

It seems acts_as_paranoid hard delete feature is not compatible
with Rails 3.2. To be able to hard delete an object (`destroy!`) that
was previously soft deleted (`destroy`), the object first has to be
"undeleted" by setting `object.deleted_at = nil`.

We don't use the hard delete feature at all in Conductor, so I think we
shouldn't test for it (this commit removes parts of specs that do).

If we want to perform hard deletes in the future, we shoud rather switch
from acts_as_paranoid to something else, because the last version of
acts_as_paranoid was released 6 years ago. No wonder it doesn't work
fully with Rails 3.2 :)
RM3766, RM3767, RM3768: Deployment spec on Travis

Stub out method calls so that specs don't depend on external services.
This should make the Deployment specs pass on Travis.
RM3764 fix (move before_destroy callbacks)

This fixes RM3764 but also other shortcomings that didn't get caught by
specs previously.

The problem is that when before_destroy callbacks are put *below*
association definitions, they are executed *after* `destroy` is called
on associated objects that are `:dependent => :destroy`. This is
currently an open issue in Rails [1]. It causes problems with our
`destroyable?` callbacks, as their whole purpose is to prevent `destroy`
from happening if needed. They should prevent destroy from happening at
the very beginning, not halfway through.

When `destroy` only manipulates data in relational DB, the issue is not
critical, because the transaction gets rolled back. However, the objects
in memory stay in `destroyed?` state, which is what caused RM3764 spec
to fail. The objects get into correct state again when `reload` is
called on them.

The situation is more problematic when `destroy` is not fully
transactional. This is the case of Instance and InstanceKey. When
attempting to destroy undestroyable instance previously, the
`destroy_instance_key` filter on InstanceKey, which deletes an instance
key via Deltacloud API, would get called before `destroyable?` filter on
Instance. The `destroyable?` filter would roll back the transaction in
Conductor's DB, but wouldn't revert the operation with Deltacloud. This
is now fixed, as `destroyable?` gets called first.

[1] https://github.com/rails/rails/issues/3458
Fix backbone session expiration

This renames the `check_session` before filter to
`check_session_expiration` and fixes a low-severity bug [1].

[1] https://github.com/aeolusproject/conductor/pull/19#issuecomment-8094708