Previously, calling `::JSON.{generate,dump}` sometimes causes
unexpected failures such as intridea/multi_json#86.

`::JSON.{generate,dump}` now bypasses the ActiveSupport JSON encoder
completely and yields the same result with or without ActiveSupport.
This means that it will **not** call `as_json` and will ignore any
options that the JSON gem does not natively understand. To invoke
ActiveSupport's JSON encoder instead, use `obj.to_json(options)` or
`ActiveSupport::JSON.encode(obj, options)`.

See [1] for why this is not a good idea.

As part of this refactor, circular reference protection in as_json has
been removed and the corresponding error class has been deprecated.

As discussed with @jeremy, circular reference error is considered
programmer errors and protecting against it is out of scope for
the encoder.

This is again based on the excellent work by @sergiocampama in #11728.

[1]: https://github.com/intridea/multi_json/pull/138#issuecomment-24468223

JSON.{dump,generate} offered by the JSON gem is not compatiable with
Rails at the moment and can cause a lot of subtle bugs when passed
certain data structures. This changed all direct usage of the JSON gem
in internal Rails code to always go through AS::JSON.{decode,encode}.

We also shouldn't be implementing `to_json` most of the time, and
these occurances are replaced with an equivilent `as_json`
implementation to avoid problems down the road.

See [1] for all the juicy details.

[1]: intridea/multi_json#138 (comment)

These methods now takes the same options as Hash#as_json, for example:

    struct = Struct.new(:foo, :bar).new
    struct.foo = "hello"
    struct.bar = "world"
    json = struct.as_json(only: [:foo]) # => {foo: "hello"}

This is extracted from PR #11728 from @sergiocampama, see also the
discussion in #11460.

Rails 4.1 has switched away from MultiJson, and does not currently
support any options on `ActiveSupport::JSON.decode`. Passing in
unsupported options (i.e. any non-empty options hash) will now raise
an ArgumentError.

Rationale:

1. We cannot guarantee the underlying JSON parser won't change in the
   future, hence we cannot guarantee a consistent set of options the
   method could take

2. The `json` gem, which happens to be the current JSON parser, takes
   many dangerous options that is irrelevant to the purpose of AS's
   JSON decoding API

3. To reserve the options hash for future use, e.g. overriding default
   global options like ActiveSupport.parse_json_times

This change *DOES NOT* introduce any changes in the public API. The
signature of the method is still decode(json_text, options). The
difference is this method previously accepted undocumented options
which does different things when the underlying adapter changes. It
now correctly raises an ArgumentError when it encounters options that
it does not recognize (and currently it does not support any options).

TL;DR The primary driver is to remove autoload surprise.

This is related to #12106. (The root cause for that ticket is that
json/add defines Regexp#to_json among others, but here I'll reproduce
the problem without json/add.)

Before:

   >> require 'active_support/core_ext/to_json'
   => true
   >> //.as_json
   NoMethodError: undefined method `as_json' for //:Regexp
     from (irb):3
     from /Users/godfrey/.rvm/rubies/ruby-2.0.0-p195/bin/irb:16:in `<main>'
   >> //.to_json
   => "\"(?-mix:)\""
   >> //.as_json
   => "(?-mix:)"

After:

   >> require 'active_support/core_ext/to_json'
   => true
   >> //.as_json
   => "(?-mix:)"

This is because ActiveSupport::JSON is autoloaded the first time
Object#to_json is called, which causes additional core extentions
(previously defined in active_support/json/encoding.rb) to be loaded.

When someone require 'active_support/core_ext', the expectation is
that it would add certain methods to the core classes NOW. The
previous behaviour causes additional methods to be loaded the first
time you call `to_json`, which could cause nasty surprises and other
unplesant side-effects.

This change moves all core extensions in to core_ext/json. AS::JSON is
still autoloaded on first #to_json call, but since it nolonger
include the core extensions, it should address the aforementioned bug.

*Requiring core_ext/object/to_json now causes a deprecation warnning*

It turns out that ActionPack depends on the decoder to parse JSON
"fragments" (e.g. '"a string"', '1', 'null', etc), so we need to
enable quirks mode on JSON.parse. Also added coverage on the decoder
side to prevent regression.

Since we are dealing with untrusted user input, we should not be
using JSON.load. According to the docs[1]:

BEWARE: This method is meant to serialise data from trusted user
input, like from your own database server or clients under your
control, it could be dangerous to allow untrusted users to pass
JSON sources into it. The default options for the parser can be
changed via the ::load_default_options method.

[1] http://www.ruby-doc.org/stdlib-2.0/libdoc/json/rdoc/JSON.html#method-i-load

This change is similar to #11736 & in same way switched with fixed string & the index of the hash for method name. the index was added because otherwise, ruby will raise Error.

U+2028 and U+2029 are allowed inside strings in JSON (as all literal
Unicode characters) but JavaScript defines them as newline
seperators. Because no literal newlines are allowed in a string, this
causes a ParseError in the browser. We work around this issue by
replacing them with the escaped version. The resulting JSON is still
valid and can be parsed in the browser.

This commit has been coauthored with Viktor Kelemen @yikulju

As reported (https://github.com/rails/rails/pull/8185#issuecomment-11702226)
this test relied on the order a hash was serialized. Comparing the parsed
hash makes the test no longer order dependent.

The encoding scheme (e.g. ☠ -> "\u2620") was broken for characters
not in the Basic Multilingual Plane.  It is possible to escape them
for json using the weird encoding scheme of a twelve-character
sequence representing the UTF-16 surrogate pair (e.g. '𠜎' ->
"\u270e\u263a") but this wasn't properly handled in the escaping code.
Since raw UTF-8 is allowed in json, it was decided to simply pass
through the raw bytes rather than attempt to escape them.

Setting options in a custom `#as_json` method had side effects.
Modifications of the `options` hash leaked outside and influenced
the conversion of other objects contained in the hash.

Reason: ActiveSupport::JSON::Variable is not used anymore internally. It
was deprecated in 3-2-stable but we reverted all the deprecation for
point releases.

See #6536 and #6546.
Conflicts:
	activesupport/lib/active_support/json/variable.rb

There are a bunch of other implicit branches that adds
1.8.x specific code that still needs to be removed. Pull
requests for those cases are welcome.

Came with this one-liner for this:

    find . -name '*.rb' | \
    xargs chardet | \
    grep -v ascii | \
    cut -d: -f1 -s | \
    xargs -n1 ruby -0777 -ne 'puts $FILENAME if $_ !~ /#.*coding:\s*utf/i'

Welcome $_.

AS Json parse_error makes a return for backwards compatibility, although it will return MultiJson::DecodeError

Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>

test json decoding with time parsing disabled with all backends and respect ActiveSupport.parse_json_times when converting to yaml
Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>

Updated the json date regex to recognize xmlschema formatted date times during json decoding. [#3031 state:resolved]
Signed-off-by: NSantiago Pastorino and Emilio Tagua <santiago+emilioe@wyeworks.com>

Fixes an issue when decoding a json string which looks like a date but is invalid. This DateTime parse error is now caught and the original string is instead passed back [#6286 state:resolved]
Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>

Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>