Bump version to 3.44.0
Support transaction isolation levels when using the JDBC transaction support

This should allow transaction isolation levels to be supported
on the following jdbc subadapters: as400, db2, derby, firebird,
hsqldb, oracle, progress, cubrid.
Support transaction isolation levels on Oracle and DB2

Both Oracle and DB2 appear to support the SQL standard way of
setting transaction isolation levels, but the non-JDBC adapters
for these databases all have custom transaction handling which
needed to be modified to set the transaction isolation level.
Raise serialization failures/deadlocks as Sequel::SerializationFailure exceptions

This builds on the support added for the ConstraintViolation
exceptions.  Having a separate exception class for these types of
errors is beneficial as these errors can usually be worked around
just by retrying the transaction.

There is no integration test for this support.  Simulating
serialization failures when testing is prone to locking up
the testing program, and the many databases that Sequel supports
handle different types of serialization issues in different ways.
Add the :retry_on and :num_retries transaction options for automatically retrying transactions

This expands the supported added a while back for the
:disconnect=>:retry option, and generalizes it to handle other
types of errors.  For example, a UniqueConstraintViolation or
SerializationFailure exception is a prime candidate for retrying
a transaction.

I've historically been against adding this as I think it's likely
that people put non-idempotent actions in their transaction blocks.
However, the recommended course of action previously has been to
use a loop in your user code, and I think this makes for a much
nicer API.  The warnings about idempotency remain, if the user wants
to ignore them, that is their problem.

In order to avoid infinite loops, the :num_retries option has been
added, and defaults to 5 retries.  With the previous code, an
infinite loop was unlikely as not much code will repeatedly raise
a disconnection error.  However, by allowing the user to pass
an exception class, we don't want to cause an infinite loop just
because they provide a CheckConstraintViolation.  For the people
that really need an infinite loop, allow an explicit nil option
for :num_replies.
Upgrade READ UNCOMMITTED and REPEATABLE READ isolation levels on Oracle
Restore previous JDBC transaction isolation level in the JDBC transaction support

This should fix issues for databases where the isolation level for
the connection persists outside the transaction in which it is set.
Disallow use of :disconnect=>:retry and :retry_on options in same transaction

In the future I want to eliminate the :disconnect=>:retry option
in favor of the :retry_on option, so I don't want to support mixed
use now.
Add unlimited_update plugin to work around MySQL warning in replicated environments

I've had a couple requests for this recently, and since the work
around is pretty simple, I think a plugin makes sense.  This could
be done by default, but I don't want to make all applications pay
the cost of the additional dataset clone when the problem only
affects a small portion of users, and even for them it only causes
a warning.
Fix warning in mysql2 adapter if used with mysql2 prerelease gem (Fixes #610)
Recognize normal SQLite error regexps on jdbc/sqlite

Travis is showing that the standard errors may occur,
and it does no harm to attempt to recognize them.
Attempt to prevent misleading exceptions on PostgreSQL

Certain error messages on PostgreSQL contain user input,
so it's possible for the user to control the exception
class generated.  The most common of these is probably
invalid input syntax, so just recognize anything
containing that as a plain DatabaseError.

Also, change the database_error_regexps description to
reflect that any enumerable is supported.  Hashes are
not ordered on ruby 1.8, so to enforce an order switch
the shared PostgreSQL adapter to use an array of pairs.
Use SQLSTATE or database error codes if available instead of regexp parsing for more specific DatabaseErrors

If the SQLSTATE is available, use it instead of parsing exception
messages with regexps.  For adapters where SQLSTATE is unavailable
or not as accurate, but a database error code can be determined,
attempt to use the database error code before parsing exception
messages.

I may refactor this in the future to allow for more flexibility
(i.e. try SQLSTATE first, fallback to regexp parsing otherwise),
but this seems to work OK for now.
Use Oracle error codes instead of parsing exception messages in the oracle adapter
Use regexps instead of SQLSTATEs on jdbc/oracle
Fix Dataset#from_self! to no longer create a self-referential dataset
Address JSON.parse vulnerabilities

It was recently discovered that the json library's JSON.parse
method is vulnerable to both denial of service and unsafe object
creation.

The simple fix is either to upgrade the json library, or pass
an option when using JSON.parse with an older json library.  Since
Sequel doesn't depend on JSON, we can't require a newer json
library, so I've added a Sequel.parse_json method that runs
the json parsing with the option set, so that user's with an older
json library are not vulnerable through Sequel.  Note that this
option and newer json library changes the behavior when parsing
json such that the json_class entry in the hash is ignored.

Sequel's core does not use JSON parsing at all, but the following
extensions and plugins that Sequel ships with do use the json
library:

* pg_array extension
* pg_json extension
* serialization plugin
* json_serializer plugin

Here's my analysis of impact for each:

pg_array extension: This only uses JSON.parse for performance
reasons to parse an array of integers that PostgreSQL returns.
This commit should not have any behavior change for this extension.

pg_json extension and serialization plugin: These could be affected
if you were storing arbitrary ruby objects in the database and
expected them to be returned as ruby object instances on retrieval.
With this commit, you will get plain hashes on retrieval.

json_serializer plugin: This plugin required significant changes
on the parsing side, since it depended on the previous json parsing
behavior, assuming that JSON.parse would return model objects.
In hindsight, this was a design mistake on my part.  To work
around this behavior, a from_json class method has been added and
can be used as a substitute for JSON.parse, with some extra
security.  However, this method is still dangerous, as any column
values can be set and arbitrary cached associations can also be set.
It is recommended that the from_self instance method be used instead,
or the json be externally validated before use if using the from_self
class method.

If the previous behavior is required in spite of the fact that it is
vulnerable, this will return the previous behavior:

  def Sequel.parse_json(v)
    JSON.parse(v, :create_additions=>true)
  end
Add Model.array_from_json to json_serializer, don't have Model.from_json handle arrays

The previous code made it easy for an attacker to force a single
instance when an array is desired, or an array of instance where a
single instance is desired.  This also makes it more similar
to the xml_serializer plugin.
Add spec for Sequel.parse_json
Make json_serializer from_json and array_from_json class methods secure by default

This makes both more similar to the from_json instance method by
default, using set or set_fields and not allowing the setting
of arbitrary columns or associations.  An :associations option
has been added to support specific associations, and the
:all_columns and :all_associations options have been added to get
the previous insecure behavior.

The json_create class method uses the :all_columns and
:all_associations options, so it should be fully backwards
compatible if you change Sequel.parse_json to use
:create_additions=>true when parsing JSON.

The json_create method is now considered deprecated, I will
probably be removing the :all_columns and :all_associations
options as well as the json_create method starting in Sequel 4.