Log message:
www/ruby-rails61: update to 6.1.3.1

Real changes are in devel/devel/ruby-activestorage61 only.

## Rails 6.1.3.1 (March 26, 2021) ##

*  Marcel is upgraded to version 1.0.0 to avoid a dependency on GPL-licensed
   mime types data.

   *George Claghorn*

Log message:
www/ruby-rails61: update to 6.1.3

Rails 6.1.3 (February 17, 2021)

[ActionPack]

* Re-define routes when not set correctly via inheritance.

    *John Hawthorn*

[ActiveRecord]

* Fix the MySQL adapter to always set the right collation and charset
  to the connection session.

    *Rafael Mendonça França*

* Fix MySQL adapter handling of time objects when prepared statements
  are enabled.

    *Rafael Mendonça França*

* Fix scoping in enum fields using conditions that would generate
  an IN clause.

    *Ryuta Kamizono*

* Skip optimised #exist? query when #include? is called on a relation
  with a having clause

  Relations that have aliased select values AND a having clause that
  references an aliased select value would generate an error when
  #include? was called, due to an optimisation that would generate
  call #exists? on the relation instead, which effectively alters
  the select values of the query (and thus removes the aliased select
  values), but leaves the having clause intact. Because the having
  clause is then referencing an aliased column that is no longer
  present in the simplified query, an ActiveRecord::InvalidStatement
  error was raised.

  An sample query affected by this problem:

    Author.select('COUNT(*) as total_posts', 'authors.*')
          .joins(:posts)
          .group(:id)
          .having('total_posts > 2')
          .include?(Author.first)

  This change adds an addition check to the condition that skips the
  simplified #exists? query, which simply checks for the presence of
  a having clause.

  Fixes #41417

    *Michael Smart*

* Increment postgres prepared statement counter before making a
  prepared statement, so if the statement is aborted without Rails
  knowledge (e.g., if app gets kill -9d during long-running query or
  due to Rack::Timeout), app won't end up in perpetual crash state for
  being inconsistent with Postgres.

    *wbharding*, *Martin Tepper*

Log message:
devel/ruby-activejob61: add package version 6.1.2.1

Active Job is a framework for declaring jobs and making them run on a
variety of queueing backends. These jobs can be everything from
regularly scheduled clean-ups, to billing charges, to
mailings. Anything that can be chopped up into small units of work and
run in parallel, really.

It also serves as the backend for Action Mailer's #deliver_later
functionality that makes it easy to turn any mailing into a job for
running later. That's one of the most common jobs in a modern web
application: Sending emails outside of the request-response cycle, so
the user doesn't have to wait on it.

The main point is to ensure that all Rails apps will have a job
infrastructure in place, even if it's in the form of an "immediate
runner". We can then have framework features and other gems build on
top of that, without having to worry about API differences between
Delayed Job and Resque. Picking your queuing backend becomes more of
an operational concern, then. And you'll be able to switch between
them without having to rewrite your jobs.

This is for Ruby on Rails 6.1.