* Add hashtag filter to profiles

GET /@:username/tagged/:hashtag
GET /api/v1/accounts/:id/statuses?tagged=:hashtag

* Display featured hashtags on public profile

* Use separate model for featured tags

* Update featured hashtag counters on-write

* Limit featured tags to 10

* Make storing and displaying application used to toot opt-in

* Revert to storing application info, and display it to the author via API

Fix #6893
Fix #9268

This is only available if the instance-wide setting isn't set and allows
people to hide their own followers count. This does not hide others' to
them.

Define `Settings::BaseController#set_body_classes` so that sub classes
inherit `Settings::BaseController` don't need to define
`#set_body_classes` agein.

* Add setting to not aggregate reblogs

Fixes #9222

* Handle cases where user is nil in add_to_home and add_to_list

* Add hint for setting_aggregate_reblogs option

* Reword setting_aggregate_reblogs label

Fix #5578

Bug in #8559

If an unresolved report for the same target account already exists,
no new notification is generated

Completely remove glitch-soc's Keyword Mutes, migrate
existing database records to CustomFilters.

Handling of client-side filters is still not implemented
in the glitch-soc front-end.

* Allow selecting default posting language instead of auto-detect

* Enable default language setting in credentials API

* Fix form saving

* Switch filtered_languages to chosen_languages

* Adjust interface

* Remove unused translations

* Send rejections to followers when user hides domain they're on

* Use account domain blocks for "authorized followers" action

Replace soft-blocking (block & unblock) behaviour with follow rejection

* Split sync and async work of account domain blocking

Do not create domain block when removing followers by domain, that
is probably unexpected from the user's perspective.

* Adjust confirmation message for domain block

* yarn manage:translations

Fix #7586

* Add preference to hide following/followers lists

- Public pages
- ActivityPub collections (does not return pages but does give total)
- REST API (unless it's your own) (does not federate)

Fix #6901

* Add preference

* Add delegation

* Fix issue

* Fix issue

Fix #7486

* Store actor type in database

* Add bot nameplate to web UI, add setting to preferences, API, AP
Fix #7365

* Fix code style issues

* No need to re-require sidekiq plugins, they are required via Gemfile

* Add derailed_benchmarks tool, no need to require TTY gems in Gemfile

* Replace ruby-oembed with FetchOEmbedService

Reduce startup by 45382 allocated objects

* Remove preloaded JSON-LD in favour of caching HTTP responses

Reduce boot RAM by about 6 MiB

* Fix tests

* Fix test suite by stubbing out JSON-LD contexts

* Add bio fields

- Fix #3211
- Fix #232
- Fix #121

* Display bio fields in web UI

* Fix output of links and missing fields

* Federate bio fields over ActivityPub as PropertyValue

* Improve how the fields are stored, add to Edit profile form

* Add rel=me to links in fields

Fix #121

* Fix #201: Account archive download

* Export actor and private key in the archive

* Optimize BackupService

- Add conversation to cached associations of status, because
  somehow it was forgotten and is source of N+1 queries
- Explicitly call GC between batches of records being fetched
  (Model class allocations are the worst offender)
- Stream media files into the tar in 1MB chunks
  (Do not allocate media file (up to 8MB) as string into memory)
- Use #bytesize instead of #size to calculate file size for JSON
  (Fix FileOverflow error)
- Segment media into subfolders by status ID because apparently
  GIF-to-MP4 media are all named "media.mp4" for some reason

* Keep uniquely generated filename in Paperclip::GifTranscoder

* Ensure dumped files do not overwrite each other by maintaing directory partitions

* Give tar archives a good name

* Add scheduler to remove week-old backups

* Fix code style issue

If a flavour has only one skin, the skin selector will be omitted.  This
omits the user[setting_skin] field, and because that's the only
user[...] field on the page, the entire user object will not be present
in the request handler's params object.

This commit accounts for that scenario by avoiding params.require(:user)
and instead picking out what we need from the params hash.

Specifically, this commit:

- changes S::TFA::{Confirmations,RecoveryCodes}Controller to derive from
  S::BaseController, because this gives us the necessary actions and
  packs
- prepends set_pack to Auth::SessionsController's action chain so that
  it takes effect in time for render :two_factor

The specs for Settings::DeletesController include an example that
sets Settings.open_deletion to false and expects the "if deletion is not
available, redirect to root" logic to run.  However, this spec does not
set up a user, which means that the spec (intentionally or otherwise)
expects this redirection to work with unauthenticated access.

We should preserve that behavior.  To do so, we prepend the deletion
check to the action chain set up by Settings::BaseController, so that
said check occurs before the authenticate_user! check.

* Make removable account migration

* Fix error during update of account migration setting

* Add notice when update account migration setting

* Add option to block direct messages from people you don't follow

Fix #5326

* If the DM responds to a toot by recipient, allow it through

* i18n: Update Polish translation (for #5669) (#5673)

There's nothing useful we can display if the destroy action messes up,
so might as well assert it does and complain loudly if it doesn't.

This avoids copy-pasting definitions of set_account.

There are two motivations for this:

1. It looks like we're going to add other features that require
   server-side storage (e.g. user notes).

2. Namespacing glitchsoc modifications is a good idea anyway: even if we
   do not end up doing (1), if upstream introduces a keyword-mute feature
   that also uses a "KeywordMute" model, we can avoid some merge
   conflicts this way and work on the more interesting task of
   choosing which implementation to use.

Also add a destroy-all action, which can be useful if you're flushing an
old list entirely to start a new one.