NEMO-296: Added a check in the fire action to avoid dangerous send
Nemo-130: Updated orders_controller and return_authorization_controller to avoid Dangerous Send

Conflicts:
	backend/app/controllers/spree/admin/orders_controller.rb
Changes to enable UT coverage reports
strip 'beta' from version # to support internal gem in a box versioning scheme
NEMO-1838 TEMPORARY change for local development - bump patch version number
Merge branch '2-2-stable' into 1838
Merge branch '2-2-stable' into 1838
NEMO-2150 add explicit check for nil variant and return false for inventory tracking

Conflicts:
	core/app/models/spree/stock_item.rb
	core/spec/models/spree/stock_item_spec.rb
Merge branch '2-2-stable' into 1838
Memoize Order.tax_zone.

In our app, this speeds up GET /checkout/update/address
from 1 minute, 15 seconds to 2 seconds.
Merge branch 'tax_zone_performance' into 1838
NEMO-1838 Add :null => false to timestamps.

In Rails 3.2, :null => false was added to migration timestamps by default.
In Rails 4.0, that change was reverted.

Since our migrations were run in Rails 3.2, our DB schemas
(including production) have :null => false.

This is a problem when a developer does

    rake db:drop
    rake db:create
    rake db:migrate

Because db/schema.rb will be different than what is checked
in to github.

To fix this without forcing migrations to be run on all
merchant databases in production, I am adding :null => false
to the EXISTING migrations. So if they get re-run, they do
the same thing they used to do.

This DOES NOT mean we have to add :null => false to NEW
migrations starting in Rails 4.0. We don't!
Merge branch '2-2-stable' into 1838

Conflicts:
	SPREE_VERSION
add configurable option to clone products without copying original images
Merge branch '2-2-nemo-stable' of github.com:godaddy/spree into 1838
Merge branch '2-2-stable' into 1838
Fix Spree issue https://github.com/spree/spree/issues/4771
When a tax rate and/or promotion is deleted we should not destroy any adjustment that was created already. The adjustments are snapshot of an order at the time when those adjustments were applied. Deleting tax rate and promotion should not affect the adjustments that are applied already even for incomplete order. It's bad user experience if we remove those adjustments silently. We just nullify the source_id.
This also gets initialized with Orders

Updates a comment with the fact that this code is also used with Orders.

At the same time, fix the order delegate. It was not previously being
called, but if it would have been it would have been broken in the case
of usage with an Order
Merge branch '2-2-stable' into 2-2-nemo-stable
Prevent multiple promotions on the same order

The desired behavior when applying multiple promotions to one order is
for Spree to choose the one that gives the largest discount, but
disable all others. This makes sure that customers cannot combine
multiple discounts.

However, before this change, this was only enforced for promotions of
the same type. I.e. you could only use one line-item-level promo per
order, and one order-level promo per order. But you could combine a
line-item-level promo with an order-level promo and they would both be
applied at the same time, combining the discounts.

With this change, we compare order-level adjustments with the sum of
all line-item adjustments per promotion. Then, we pick the best
promotion and disable all others.

cc/ @huoxito -- I think you are familiar with this code.
cc/ @gmacdougall, @cbrunsdon, as we discussed on IRC
cc/ @athal7 who paired with me on this.