update guild bans api

Merge pull request #1305 from ZaneH/feat/handle-github-webhook ...

Implement GitHub-compatible webhook

Modern pins endpoints

Add emoji source endpoint

Add endpoint to get account standing

Prettier

Fix forgotten function signature changes

Make IP/user-agent validation in CDN work

sign attachment on sending message

Sign media per user

Add options to erquire IP or User Agent to access CDN

Fix typeorm queries no longer allowing empty where clauses

Update some dependencies, fix nix

Fix the fix ...

this should actually be what's intended

Check for old password when setting new ...

Checks for password

Proxy avatar URL + adjust event logic ...

I've proxied the URLs with `getProxyUrl` specifying the size as 80x80.

I've also adjusted the event logic so that unstarring doesn't trigger an
alert and I've disabled the 'watch' event because Discord doesn't use
it either.

Make tsc happy when using strings as Date in embed ...

Validation on embeds has interesting behavior. Embeds have a `timestamp`
property that is of type `Date`. However when providing a Date,
`WebhookExecuteSchema` silently ends the operation.

The resolution was to use strings and to annotate them with `//
@ts-expect-error`. This was not my first choice, but it was the best
option I saw.

The other option is to allow `Embeds` to pass strings as a timestamp but
I'd want a second opinion before making that change.

Refactor `/github` endpoint into it's own file

Capitalize `ref_type` when using in embed ...

The GitHub API provides `ref_type` as lowercase. For consistency, this
adds a utility function and makes use of it when formatting the `create`
event from GitHub.

tag => Tag
branch => Branch

Implement webhook handler for GitHub ...

I've created a middleware that runs when `/github` is appended to the
webhook URL. The middleware parses the GitHub webhook and turns it into
usable embeds.

Fix the creation of guilds from templates ...

The biggest hold-up was missing fields (`premium_tier`,
`welcome_screen`, etc.) but it looks like someone has provided a
helpful function called `createGuild(...)` to provide sensible default
values.

This commit fixes the errors related to creating a guild from a
template. I've also refactored the code to include roles and channels in
the template.

To make sure that the @everyone role is cloned correctly, when
creating the guild from a template, we check if the role's ID
matches the template's `source_guild_id`. If it does, we set the
@everyone role to the new guild's ID.

Set `premium_tier` to 0 when creating guild from template ...

I think we'll need to discuss the proper way to provide default values
here. `premium_tier` for example should never be provided from the
template so it's fine going after the spread operator.

This commit still doesn't allow guilds to be created from template
because the next error is that `welcome_screen` doesn't exist. Our
options:

1. Provide default values in the ORM
2. Provide default values in the guild creation process
3. Throw an error if the template is missing values

Resolves: #1283 but creates a new issue

Await guild creation to fix a race condition ...

`Promise.all(...)` runs these simultaneously, yet role depends on the
guild to be created first. This can lead to a race condition. I've
awaited role creation too because the call to `Member.addToGuild(...)`
relies on the role to be created.

Fix PATCH Template route implementation ...

The previous PATCH implementation was creating a new template rather
than editing the existing template. This resulted in all requests
failing because it was missing more than one required field.

Resolves: #1281

Add OP to message.mentions when replied to ...

The `message.message_reference` stores:

1. `message_id`
2. `channel_id`
3. `guild_id`

We use the `message_id` and `channel_id` to `.findOne(...)` Message, and
find the author. If the author is the same as OP, we skip (so replying
to yourself doesn't add you to the mentions array) otherwise, it adds
the author_id to the mentions array.

Resolves: #1247

Preserve reactions when a message is edited ...

Resolves #1241

Properly filter existing embed links ...

In a previous PR, I was checking if the `.url` property existed, the
correct fix is to remove any embed that isn't a rich embed
type (non-link).

See also: #1296

Start fresh when updating embeds for links ...

In a previous commit I was attempting to be clever by only
replacing/removing embeds if necessary. This not only made the logic
more confusing but introduced a bug that would allow for orphaned
embeds when updating the search params of a URL.

This commit will remove all embeds that have a `.url` property and start
fresh. This simplifies the code and eliminates the aforementioned bug.

Fix various issues with embeds on message updates ...

The `postHandleMessage` function is parsing links and adding them to the
EmbedCache table if necessary. In the previous implementation, message
updates would push to the embeds unconditionally.

This commit parses links from the message and:

1. Normalizes the URLs
  - Useful for deduplicating similar URLs
2. Remove embeds with matching normalized URLs
  - Leaves all embeds except for ones with a `.url` property matching
  the updated message
  - This allows embeds to be re-ordered if the URL is moved
3. If no normalized URLs are found, remove all embeds
4. Take the deduplicated + normalized URLs and add an embed to the message and
insert into the EmbedCache table (if necessary)

This enables:

1. Embeds to be re-ordered by re-ordering links
2. Embeds to be removed by removing links

and fixes:

1. Duplicate embeds being attached to a message when edited

Add validation to date_of_birth registration field ...

Resolves: #1020