Add support for Stoat bridge

[sh4sh]

It'd be nice to add an integration for Stoat since it's had a surge in popularity lately.
I am sorta brain/research dumping this and I am very far from an expert. You are encouraged to comment, criticize, tell me it's all wrong.

Helpful:

• Many resources and most of the API still refer to Stoat's former name, Revolt. They might still be compatible.
• Stoat's API looks somewhat similar to Discord, and RevoltGo uses webhooks like Discord's bridge does, so we can probably maybe loosely follow the Discord bridge design
• Stoat Github organization, links to project repos docs
• Stoat Developer docs
• Awesome Stoat, list of community libraries bots etc.
• sentinelb51/revoltgo, seems like the best maintained Go wrapper.

Things we will for sure need to add:

1. gateway/bridgemap/bstoat.go to register with matterbridge's Gateway
2. RevoltGo dependency in go.mod
3. the actual bridge at bridge/stoat/stoat.go

What do we put in bridge/stoat/stoat.go?

Listed in order of connection flow (kinda):

• BStoat struct, Discord example. Ours will ofc look different. we for sure need a *revoltgo.Session, also userID, and channel ID/name (to match channels.go i think?)
  We will prob need to find a way to map Channel IDs to human-readable channel names since revoltgo doesn't seem to do it for us?

• New(), Discord example creates the initial bridge instance when Gateway calls it, initialize struct, maps, config flags. no actual network calls.
  -- initialize cache here, if needed! revoltgo has its own cache, so we should check if the thing we need is already stored there. If not, we can just add cache here (or modify revoltgo I guess)

• Connect(), Discord example. actual first network calls!
  -- read token from config (required)
  -- read server from config if set, call revoltgo.SetBaseURL() from endpoints.go
  -- create session with revoltgo.New(token) from session.go
  -- add event handlers using AddHandler() from session.go, we can add the events we want from events.go (like EventMessage, EventMessageUpdate, EventMessageDelete). Probably looks similar to Discord's handlers.go
  -- finally we can call Open() from session.go to establish our connection
  -- Discord seems to do some stuff with channel lists here, maybe we need as well?

• JoinChannel(), Discord example. I don't fully understand what we want here.
  -- do we also have to resolve any ID<->Name things here?
  -- i haven't looked too closely at how to resolve channel names but maybe useful: revoltgo caches channel info in state.go

• Send(), Discord example. This is the outbound message function! Gateway calls it and passes config.Message
  -- do we also have to resolve any ID<->Name things here?
  -- plug in event handlers for events that occur when we send a message, again from revoltgo's events.go. Since Gateway is calling this, do we have to store it in config.Message first?
  -- events we probably want to support: EventMessage, EventMessageUpdate, EventMessageDelete
  -- attachments/file uploads? do they go here? check AttachmentUpload() in session.go, guessing from the function you'll also need file.go
  -- Do we need other stuff in here
  -- We probably do but I need to take a break for now

• Disconnect() using Close() in session.go, short and sweet. Discord example.

Do we need anything else? Am I missing something, or a lot of things? Lemme knowww

[sh4sh]

nice-to-have:

• Masquerade support (so that users show up as their own nicknames, and not as the Bot name. Requires Masquerade server permission. actually now that I type this, maybe this is more than nice-to-have lol)
• Reactions support (in event.go). how many bridges actually support this? xmpp<->discord sure doesn't
• Typing indicators? is that shooting too high? from events.go

[kousu]

• We will prob need to find a way to map Channel IDs to human-readable channel names since revoltgo doesn't seem to do it for us?

It's got .Name and .Description! But you won't need them; in the matterbridge config you generally have to name things with their unique IDs like

[[gateway.inout]]
account="discord.bridge"
channel="ID:14534744792938471648"

---

Masquerade support (so that users show up as their own nicknames, and not as the Bot name. Requires Masquerade server permission. actually now that I type this, maybe this is more than nice-to-have lol)

Yeah! Discord does this, but it still marks it as from a bot, which is a fair trade off. I forget what permission I had to turn on to make this go.

Reactions support (in event.go). how many bridges actually support this? xmpp<->discord sure doesn't

but reactions CHANGE EVERYTHING.

..huh, the updated matterbridge still has zero attempt to bridge reacts though, there's nothing in this

matterbridge/bridge/config/config.go

Lines 37 to 51 in 8a6d061

	type Message struct {
	Text string `json:"text"`
	Channel string `json:"channel"`
	Username string `json:"username"`
	UserID string `json:"userid"` // userid on the bridge
	Avatar string `json:"avatar"`
	Account string `json:"account"`
	Event string `json:"event"`
	Protocol string `json:"protocol"`
	Gateway string `json:"gateway"`
	ParentID string `json:"parent_id"`
	Timestamp time.Time `json:"timestamp"`
	ID string `json:"id"`
	Extra map[string][]interface{}
	}

and literally the only mention in the codebase is about how they drop messages with reactions because they can't handle them

[kousu@laptop matterbridge]$ git grep react
bridge/mattermost/helpers.go:   // if the message has reactions don't repost it (for now, until we can correlate reaction with message)
changelog.md:- mattermost: ignore edited messages with reactions
docs/protocols/discord/account.md:(based upon https://github.com/reactiflux/discord-irc/wiki/Creating-a-discord-bot-&-getting-a-token)
go.sum:github.com/shurcooL/reactions v0.0.0-20181006231557-f2e0b4ca5b82/go.mod h1:TCR1lToEk4d2s07G3XGfz2QrgHXg4RJBvjrOozvoWfk=

So uh, there's some good work to roll up sleeves and go there

Do we need anything else? Am I missing something, or a lot of things? Lemme knowww

No, I mean, that's literally the whole lifecycle: connect, join, receive, send, disconnect. If you just implement these one step at a time and watch your logs I think it'll come together. I always get so excited when the logs show something went where I meant it to.