Most importantly, the original request thread must yield its share lock
while waiting for the live thread to commit -- otherwise a request's
base and live threads can deadlock against each other.

While we know no user code is running, we should do as much loading as
we can. That way, all the threads will then be able to resume running
user code together.

Otherwise, only the last arriving thread would get to do its load, and
would then return to userspace, leaving the others still blocked.

- Instead of using `to_f.phase`, just use `to_f.negative`?.
- This change works same for all cases except when number is "-0.0".
      -0.0.to_f.negative? => false
      -0.0.to_f.phase? => pi
- So -0.0 will be treated as positive from now onwards.
- So this change reverts changes from https://github.com/rails/rails/pull/6512.
- But it should be acceptable as we could not find any currency which
  supports negative zeros.

This fixes ⚠ previous definition of download was here

When `rails console` or `rails server` are used along with a logger set to output to `STDOUT` then the contents will show up twice. This happens because the logger is extended with `ActiveSupportLogger.broadcast` with a destination of STDOUT even if it is already outputting to `STDOUT`.

Previously PR #22592 attempted to fix this issue, but it ended up causing NoMethodErrors. A better approach than relying on adding a method and flow control is to inspect the log destination directly. For this `ActiveSupport::Logger.logger_outputs_to?` was introduced

```ruby
logger = Logger.new(STDOUT)
ActiveSupport::Logger.logger_outputs_to?(logger, STDOUT)
# => true
```

To accomplish this we must look inside of an instance variable of standard lib's Logger `@logdev`. There is a related Ruby proposal to expose this method in a standard way: https://bugs.ruby-lang.org/issues/11955

This reverts related commits due to #22917.

  - Adds new key/value pair to payload when an exception is raised
    e.g. `:exception_object=> #<RuntimeError: FAIL>`
  - Updates relevant test
  - Adds CHANGELOG entry

- uses instance defined level if no custom local log level defined
- Keeps track of local log level per [ thread + object-instance ]
- prevents memory leakage by removing local level hash key/value on #silence method exit
- avoids the use of Thread local variables

Suppress warning (warning: ambiguous first argument; put
parentheses or a space even after `/' operator)

Also, added a test case to make sure that the default deprecation horizon is
always bigger than the current Rails version.

This test needs to have a require for the Listen gem or else it returns
an error when run by itself or with a certain order in the Active
Support tests. We use `silence_warnings` because Listen has some
warnings about private methods. It's already silenced when it's required
in Active Support EventedFileUpdateChecker.

```
1) Error:
EventedFileUpdateCheckerTest#test_should_not_execute_the_block_if_no_paths_are_given:
NameError: uninitialized constant EventedFileUpdateCheckerTest::Listen
    test/evented_file_update_checker_test.rb:21:in `teardown'
```

The test was was in here twice so we were seeing this error:

```
activesupport/test/caching_test.rb:658:
warning: method redefined; discarding old test_local_cache_of_read_nil
activesupport/test/caching_test.rb:634:
warning: previous definition of test_local_cache_of_read_nil was here
```

Add thread_m/cattr_accessor/reader/writer suite of methods for declaring class and module variables that live per-thread

When setting the Rails logger to log to STDOUT, it would broadcast the
log twice in development. This adds a setting that will prevent messages
from being broadcast to multiple logs, while still allowing calls to
`#close`, `#level=`, `#progname=`, and `#formatter=` to be broadcasted.

Fixes #14769, #11415

Better English.

Fixes https://github.com/rails/rails/issues/22477.

When I improved the caching instrumentation in
edd33c08, I inadvertently changed the
order of AS notifications when there is a cache miss.

The issue is that on the exit from Instrumenter#instrument section,
an Evented listener will run into an error because its thread local
(Thread.current[:_timestack]) has not been set up by the #start
method (this obviously happens because the Evented listeners didn't
exist at the time, since no subscribtion to that section was made yet).

Note: support for subscribing to instrumented sections, while being
inside those instrumented sections, might be removed in the future.

Maybe fixes #21873.

The failure have returned, so disabling the tests again. (The upgrade is
fine to keep.)

In listen 3.0.4 and below, the `#stop` method on the notification
backends are a no-op, meaning that we are leaking them per test. This
ended up triggering another bug in Ruby that causes our builds to fail
randomly on CI.

listen bug: https://github.com/guard/listen/issues/353
ruby bug: https://bugs.ruby-lang.org/issues/11744

There is a known issue with the listen tests that casuses files to be
incorrectly GC'ed even when they are still in-use. The current is to
only run them in isolation to avoid randomly failing our test suite.

Looking at the history of this file it seems this code was never actually used.

Before

./Users/Juan/dev/rails/activesupport/test/file_update_checker_shared_tests.rb:20: warning: instance variable @tmpdir not initialized

After

No warnings