Make AR::Base#touch fire the after_commit and after_rollback callbacks

[airhorns]

I expected

class Product < ActiveRecord::Base
  after_commit :expire_cache

  def expire_cache
    puts "cache expired"
  end

product.touch

to output "cache expired", but it doesn't, and it used to in Rails 3.0. This PR brings back that functionality by making touches call after_commit callbacks, woo!

We relied on after_commit callbacks being fired by touches to do things like expire caches, send documents to our search cluster, bump versions in Redis, etc. When we upgraded to 3.2, we found this problem and had to go and add after_touch callbacks to all those places to get touches to cause the same changes in the system. We make pretty heavy use of touches to bump timestamps up the association chain and whatnot, so they are a principle instigator of attribute change in the system. I think having to add both callbacks to really get a callback fired when stuff changes is sucky because it means client code has to deal with de-duplication if both callbacks fire, client code has to be aware of the semantic differences of when they fire, and before this change there is no way to get called back to when a record's timestamp bump has definitely been committed to the database.

Thanks for any feedback you can give me!

@carlosantoniodasilva this is a follow up to #12026 on top of 4-0-stable, is this what you need?

[arthurnn]

👍

[pftg]

Need one line before on_after_commit method!

[pftg]

Please add Changelog

[airhorns]

@pftg updated, thanks for the feedback

[ryansch]

👍

[airhorns]

Bump?

[ryansch]

We've been running this in production via a monkey patch for 4 months. Works as intended.

[airhorns]

Us at Shopify too

[carlosantoniodasilva]

Hey folks, sorry I missed this one, already marked it here to take a look as soon as I find some time here. Thanks!

[arthurnn]

I think we wanna close this PR, and open another one against master... =( , than we backport if needed.

[arthurnn]

is this necessary?