Clear @cache_keys cache after update_all, delete_all, destroy_all

[kamipo]

The calculated cache key is cached on a relation, but there is no way to
re-calculation even if mutation to collection on a relation is happened.

The @cache_keys cache should be cleared at least after update_all,
delete_all, destroy_all.

Related to #41784.

[rafaelfranca]

I find tap very confusing, but up to you if you are going to use it

[kamipo]

There are two main reasons why I've used tap here.

The first one is destroy_all already uses that, and the ensure block-like cleaning up in tap is a little common pattern in the codebase.

rails/activerecord/lib/active_record/relation.rb

Lines 577 to 579 in 5b10aca

	def destroy_all
	records.each(&:destroy).tap { reset }
	end

% git grep -n '\.tap { reset' lib
lib/active_record/associations/collection_proxy.rb:473:        @association.delete_all(dependent).tap { reset_scope }
lib/active_record/associations/collection_proxy.rb:500:        @association.destroy_all.tap { reset_scope }
lib/active_record/associations/collection_proxy.rb:619:        @association.delete(*records).tap { reset_scope }
lib/active_record/associations/collection_proxy.rb:691:        @association.destroy(*records).tap { reset_scope }
lib/active_record/relation.rb:491:      klass.connection.update(stmt, "#{klass} Update All").tap { reset }
lib/active_record/relation.rb:578:      records.each(&:destroy).tap { reset }
lib/active_record/relation.rb:619:      klass.connection.delete(stmt, "#{klass} Destroy").tap { reset }

The second one is that I'd not like to name what the return value of klass.connection.update is.

The return value of klass.connection.delete is named as affected, but the return value of klass.connection.update is actually found/matched rows count (#25370), not affected rows.

If there is no strong objection to those points, I would like to continue to use it here.

[rafaelfranca]

Like I said it is up to you. But tap and map are too close to me that sometimes I read that code and I think it is returning an array of items with the return of reset.

[kamipo]

I see your point.

Just as the tap { break expr } idiom was added as yield_self { expr } / then { expr } in Ruby, the ensure block-like tap idiom may be invented in a better way in the future (e.g. as Golang like defer: https://github.com/tagomoris/deferral).

In the meantime, leave this idiom as it is for now.