Update docs for change in transaction callback exceptions

07d3d402 changed how exceptions are handled in after_commit
and after_destroy callbacks.  This commit updates the 5.0
release notes and the  ActiveRecord callback guide to reflect
the new behavior.

[ci skip]

guides/source/5_0_release_notes.md

@@ -797,6 +797,14 @@ Please refer to the [Changelog][active-record] for detailed changes.
     than the current time.
     ([Pull Request](https://github.com/rails/rails/pull/18956))
 
+*   Change transaction callbacks to not swallow errors.
+    Before this change any errors raised inside a transaction callback
+    were getting rescued and printed in the logs, unless you used
+    the (newly deprecated) `raise_in_transactional_callbacks = true` option.
+
+    Now these errors are not rescued anymore and just bubble up, as the other callbacks.
+    ([commit](https://github.com/rails/rails/commit/07d3d402341e81ada0214f2cb2be1da69eadfe72))
+
 Active Model
 ------------
 

guides/source/active_record_callbacks.md

@@ -431,4 +431,4 @@ class PictureFile < ApplicationRecord
 end
 ```
 
-WARNING. The `after_commit` and `after_rollback` callbacks are guaranteed to be called for all models created, updated, or destroyed within a transaction block. If any exceptions are raised within one of these callbacks, they will be ignored so that they don't interfere with the other callbacks. As such, if your callback code could raise an exception, you'll need to rescue it and handle it appropriately within the callback.
+WARNING. The `after_commit` and `after_rollback` callbacks are called for all models created, updated, or destroyed within a transaction block. However, if an exception is raised within one of these callbacks, the exception will bubble up and any remaining `after_commit` or `after_rollback` methods will _not_ be executed. As such, if your callback code could raise an exception, you'll need to rescue it and handle it within the callback in order to allow other callbacks to run.