For better or worse, anonymous `*` args will allocate arrays.  Ideally,
the interpreter would optimize away this allocation.  However, given the
number of times we call `html_safe` it seems worth the shedding idealism
and going for performance.  This line was the top allocation spot for a
scaffold (and presumably worse on real applications).

A full write-preferring wait can lead to deadlock.

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.

This is a reaction to a [bug] we hit in web-console. The cause of it was
a `Kernel` extension called `#console` that was public and was fighting
over Railties with console block to be run on `rails console`. We solved
it by making the method private. We did that through `module_function`
so `::Kernel.console` can be invoked even in `BasicObject`.

I'm proposing to make most of the core Active Support `Kernel`
extensions `module_function` as well. Those are currently public and we
are polluting every `Object` public interface with them.

```ruby
>> Object.new.respond_to? :silence_warnings
=> true

>> Object.new.respond_to? :with_warnings
=> true

>> Object.new.respond_to? :enable_warnings
=> true

>> Object.new.respond_to? :suppress
=> true
``

Some extensions like `Kernel#class_eval` should be public, but most of
them don't really need to be.

[bug]: https://github.com/rails/web-console/issues/184

railties uses method_source, activesupport does not.  I assume code was refactored and the dependency wasn't removed.

All modern Rubies ship JSON as part of stdlib.  Using the gem actually hurts multi-platform support due to build difficulties on Windows.

And improve changelongs.

[ci skip]

[ci skip]

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.

- Followup of https://github.com/rails/docrails/commit/10bc49710b7205a6172c3e072b3c77114fefd952

- 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.

[ci-skip]

[ci skip]
Fixes #20808

[Vipul A M & Julio Lopez]

This fixes ⚠ previous definition of download was here

The Time.use_zone method will only affect ActiveSupport::TimeWithZone
instances created inside of the block passed to Time.use_zone. This
could be confusing when fetching a model and then reading the attribute
before the block and it not changing afterwards because Active Record
caches the conversion from the database value.

Since changing the behavior of Active Record to recreate the value on
every attribute read is an expensive operation the best we can do is
to document the issue.

Fixes #23195.

[ci skip]

Instance level writers can have an impact on how the Active Model /
Record objects are saved.  Specifically, they can be used to bypass
validations.  This is a problem if mass assignment protection is
disabled and specific attributes are passed to the constructor.

CVE-2016-0753

this will avoid timing attacks against applications that use basic auth.

CVE-2015-7576

The line filter parsing added to ActiveSupport::TestCase is only half the story
to enable line filtering. The other half, of adding the patterns to the options,
is done in the Minitest plugin that Railties has.

Thus it makes more sense to have the filter in Railties with the other half and
all the line filtering tests.

Move the filter and extend Active Support in an initializer, so that when users
or `rails/all.rb` require `rails/test_unit/railtie` we can still filter by line.

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.

petabyte and exabyte numeric conversion has been added after the 5.0.0.beta1 release.
ref: 85048e90

[ci skip]