Don't track IP addresses for post appeals, post flags, tag aliases, tag
implications, or user feedbacks. These things are already tightly
limited. We don't need IPs from them to detect sockpuppets.
Fix various cases where db/structure.sql either didn't match the
production db or didn't match the db structure produced when running
migrations from a fresh install.
Bug: running migrations on a fresh database failed when we got to a
migration adding a posts.uploader_ip_addr index on 2019-11-11. It failed
because the index already existed.
The index already existed because we used to have it at one point, until
it was removed by another migration on 2015-01-20. This migration didn't
correctly remove the index though, because it tried to remove a
posts.source index first, which failed because this index didn't exist
(it probably existed only in production). This error was swallowed,
causing the migration to silently skip removing the posts.uploader_ip_addr
index, which eventually blew up when we tried to add the index again
later on.
Add a new IP address search page at /ip_addresses. Replaces the old
search page at /moderator/ip_addrs.
On user profile pages, show the user's last known IP to mods. Also add
search links for finding other IPs or accounts associated with the user.
IP address search uses a big UNION ALL statement to merge IP addresses
across various tables into a single view. This makes searching easier,
but is known to timeout in certain cases.
Fixes#4207 (the new IP search page supports searching by subnet).
Drop the creator_id and updater_id fields from wiki pages. These fields
had several issues:
* The creator_id field was inconsistent with the wiki_page_versions
table. Apparently during the migration to Danbooru 2 in 2012-2013 the
creator_id field got reset to whoever last updated the wiki at that
point in time.
* Saving a wiki would set the updater_id even when nothing actually
changed. This also caused the updated_at timestamp to get bumped.
Because of this, anything that saved a wiki, including things like
creating aliases or implications, would bump the updater_id and
updated_at even though the wiki didn't actually change. This meant
these fields weren't consistent with the wiki_page_versions history.
Changes:
* Remove `creator_name` field from the /wiki_pages.json API.
* Remove creator name search option from /wiki_pages/search.
Add a dtext_links table for tracking links between wiki pages. This is
to allow for broken link detection and "what links here" searches, among
other uses.
Remove all infrastructure around approving or rejecting user name
changes. Name changes haven't been moderated for several years.
* Remove status, approver_id, change_reason, and rejection_reason fields.
* Remove approve and reject controller actions.
Fixup for 9c34d5cc3. Default to member level in the database because
setting it in `customize_new_user` clobbered user levels set by factory
bot in tests, which broke the test suite.
* Change the source index on posts from `(lower(source) gin_trgm_ops) WHERE source != ''`
to just `(source gin_trgm_ops)`. The WHERE clause prevented the index
from being used in source:<url> searches because we didn't specify
the `source != ''` clause in the search itself. Excluding blank
sources only saved a marginal amount of space anyway. This fixes
timeouts in source:<url> searches and in the bookmarklet (since we do
a source dupe check on the upload page too).
* Also switch from indexing `lower(name)` to `name` on pools and users.
We don't need to lowercase the column because GIN indexes can be used
with both LIKE and ILIKE queries.
* Drop support for `source:pixiv/artist-name` searches. This was a hack
that only worked on old pixiv urls that haven't been used for years.
* Replace the old SourcePattern(lower(source)) index with a trigram index.
