Remove the word "mongrel" from documents

Currently mongrel is not maintained.
And it couldn't be built with any Ruby versions that
supported by Rails.

It is reasonable to remove the word "mongrel" in order to avoid
confusion from newcomer.

activesupport/lib/active_support/backtrace_cleaner.rb

@@ -14,7 +14,7 @@ module ActiveSupport
   #
   #   bc = BacktraceCleaner.new
   #   bc.add_filter   { |line| line.gsub(Rails.root.to_s, '') } # strip the Rails.root prefix
-  #   bc.add_silencer { |line| line =~ /mongrel|rubygems/ } # skip any lines from mongrel or rubygems
+  #   bc.add_silencer { |line| line =~ /puma|rubygems/ } # skip any lines from puma or rubygems
   #   bc.clean(exception.backtrace) # perform the cleanup
   #
   # To reconfigure an existing BacktraceCleaner (like the default one in Rails)
@@ -59,8 +59,8 @@ module ActiveSupport
     # Adds a silencer from the block provided. If the silencer returns +true+
     # for a given line, it will be excluded from the clean backtrace.
     #
-    #   # Will reject all lines that include the word "mongrel", like "/gems/mongrel/server.rb" or "/app/my_mongrel_server/rb"
-    #   backtrace_cleaner.add_silencer { |line| line =~ /mongrel/ }
+    #   # Will reject all lines that include the word "puma", like "/gems/puma/server.rb" or "/app/my_puma_server/rb"
+    #   backtrace_cleaner.add_silencer { |line| line =~ /puma/ }
     def add_silencer(&block)
       @silencers << block
     end

activesupport/lib/active_support/cache/memory_store.rb

@@ -4,7 +4,7 @@ module ActiveSupport
   module Cache
     # A cache store implementation which stores everything into memory in the
     # same process. If you're running multiple Ruby on Rails server processes
-    # (which is the case if you're using mongrel_cluster or Phusion Passenger),
+    # (which is the case if you're using Phusion Passenger or puma clustered mode),
     # then this means that Rails server process instances won't be able
     # to share cache data with each other and this may not be the most
     # appropriate cache in that scenario.

guides/source/caching_with_rails.md

@@ -381,7 +381,7 @@ config.cache_store = :memory_store, { size: 64.megabytes }
 ```
 
 If you're running multiple Ruby on Rails server processes (which is the case
-if you're using mongrel_cluster or Phusion Passenger), then your Rails server
+if you're using Phusion Passenger or puma clustered mode), then your Rails server
 process instances won't be able to share cache data with each other. This cache
 store is not appropriate for large application deployments. However, it can
 work well for small, low traffic sites with only a couple of server processes,

guides/source/configuring.md

@@ -1198,7 +1198,7 @@ development:
   timeout: 5000
 ```
 
-Since the connection pooling is handled inside of Active Record by default, all application servers (Thin, mongrel, Unicorn etc.) should behave the same. The database connection pool is initially empty. As demand for connections increases it will create them until it reaches the connection pool limit.
+Since the connection pooling is handled inside of Active Record by default, all application servers (Thin, Puma, Unicorn etc.) should behave the same. The database connection pool is initially empty. As demand for connections increases it will create them until it reaches the connection pool limit.
 
 Any one request will check out a connection the first time it requires access to the database. At the end of the request it will check the connection back in. This means that the additional connection slot will be available again for the next request in the queue.
 

guides/source/initialization.md

@@ -318,7 +318,7 @@ def parse!(args)
   args, options = args.dup, {}
 
   opt_parser = OptionParser.new do |opts|
-    opts.banner = "Usage: rails server [mongrel, thin, etc] [options]"
+    opts.banner = "Usage: rails server [puma, thin, etc] [options]"
     opts.on("-p", "--port=port", Integer,
             "Runs Rails on the specified port.", "Default: 3000") { |v| options[:Port] = v }
   ...

guides/source/security.md

@@ -131,7 +131,7 @@ It works like this:
 * The user takes the cookie from the first step (which they previously copied) and replaces the current cookie in the browser.
 * The user has their original credit back.
 
-Including a nonce (a random value) in the session solves replay attacks. A nonce is valid only once, and the server has to keep track of all the valid nonces. It gets even more complicated if you have several application servers (mongrels). Storing nonces in a database table would defeat the entire purpose of CookieStore (avoiding accessing the database).
+Including a nonce (a random value) in the session solves replay attacks. A nonce is valid only once, and the server has to keep track of all the valid nonces. It gets even more complicated if you have several application servers. Storing nonces in a database table would defeat the entire purpose of CookieStore (avoiding accessing the database).
 
 The best _solution against it is not to store this kind of data in a session, but in the database_. In this case store the credit in the database and the logged_in_user_id in the session.
 

railties/lib/rails/commands/server.rb

@@ -23,7 +23,7 @@ module Rails
 
         def option_parser(options)
           OptionParser.new do |opts|
-            opts.banner = "Usage: rails server [mongrel, thin etc] [options]"
+            opts.banner = "Usage: rails server [puma, thin etc] [options]"
             opts.on("-p", "--port=port", Integer,
                     "Runs Rails on the specified port.", "Default: 3000") { |v| options[:Port] = v }
             opts.on("-b", "--binding=IP", String,