Initial iteration of calendar event format and parsing

[QuantumManiac]

Description

Summary

This PR lays out the initial iteration for calendar event metadata, to be read by Minerva so it can do its stuff, along with functionality to parse events fetched from the Google Calendar API into something usable by Minerva's functions

Google Calendar Event Metadata Format

As with old minerva, the majority of the event metadata that minerva will make use of is contained within the description.

While previously we used JSON for this metadata, this time around we're moving to using plaintext as it will (in theory) be less prone to completely breaking anything when manually edited by the user instead of using /meeting edit command. This is important, as the plan for configuring event metadata for this iteration is to do it by editing the description directly through Google Calendar instead of using minerva functionality in slack (e.g. the initialize button, the /meeting edit modal)

An example valid description is found below

#general
https://meet.waterloorocketry.com
this is the event description
Wow, ain't this great.
look at how I'm demonstrating multi-line-ness

This is what you would put in the "description" field for a calendar event. Let's break things down.

The first two lines of the description represent the (current iteration) of the minerva metadata section, which is where you will configure parameters required for minerva to do its job. These two lines can be omitted if you do not want minerva to pick up on this event. In addition, these lines can be in any order, as long as they go before the actual event description, which follows afterwards.

The first line configures the channel is associated with the event, for minerva to post event reminders to and such. A single channel must be specified.

The second line is optional, and configures the meeting link for the event. This link needs to start with http or https for minerva to pick up on it.

As with old minerva, the "location" field will be used to specify the physical meeting location, if applicable

Keep in mind that this is a first iteration! I would really like some reviews, especially from frequent users of minerva, to see how we can improve on this format.

This PR closes #16 .

Developer Testing

• Implemented unit testing for all new functionality - see unit test logs.

Reviewer Testing

• Not much testing can be done from the reviewers' side as this mostly just implements the helper functions to be used by other pieces of minerva's functionality
• Trust the unit tests :) (no actually don't, check if I missed any cases if you can)

---

This change is 

[BluCodeGH]

I don't think making people write yaml by hand is going to end well. Even though it's simple people wont remember the format and will do things like use =, or incorrect whitespace, or etc.

I'd propose that the description follows this format:

#electrical
https://meet.waterloorocketry.com/2
Optional extended description

And tbh I wouldn't even make that line ordering mandatory. We can pretty easily pull out the #channel and URL.

Also I'd suggest only allowing a single channel to be specified and using a fixed list of subsystem channels to notify single-channel-guests in. If we really feel the need in the future we can add some special syntax to specify additionalChannels but imo lets optimize for the 95% use case.

[BluCodeGH]

Looks fine at a glance, though tbh I wouldn't even mandate metadata be in the first two lines. Just use the first channel-looking thing and first url-looking thing we find.

[BluCodeGH]

What would initially set up that placeholder text? The workflow I'm envisioning is that people manually create the calendar event and fill out the description / options from the google calendar web ui, all one step.

Fundamentally I really disagree with adding more options than a single channel and meeting link here. We need this to be as dead simple as possible for it to be effectively usuable.

[QuantumManiac]

Looks fine at a glance, though tbh I wouldn't even mandate metadata be in the first two lines. Just use the first channel-looking thing and first url-looking thing we find.

I'll keep a proper ordering for the metadata, at least for now. Having it parse through an entire description and grabbing whatever it can find that looks like a channel or URL sounds annoying for the cases where we actually do have things like non-meeting URLs in the text.

What would initially set up that placeholder text? The workflow I'm envisioning is that people manually create the calendar event and fill out the description / options from the google calendar web ui, all one step.

Yeah, the intention is to have the configuration specified by the user as they create the calendar event. No creating the event and then minerva detecting it and populating it or anything.

Fundamentally I really disagree with adding more options than a single channel and meeting link here. We need this to be as dead simple as possible for it to be effectively usuable.

Yep, agreed for the most part. In its current implementation, the only thing that you need to have in the event description for minerva to make use of it is the channel to post reminders to. Everything else is completely optional. That being said, I don't see anything wrong with being able to add additional optional options such that it's kept dead simple for basic usability but still has a bit more functionality the so-called power users

At least for now, I think meeting link and channel is good. As you mentioned, this covers the 95% use-case, and we can add more functionality in once new minerva is actually put to use and we identify any defiencies.