feat: Add room info for export

[alfredzimmer]

I've refactored the parsing system to correctly handle cases where a single lecture has multiple rooms.

Note on Database Changes:
Since this PR includes a schema migration and I don't have extensive experience with database changes, I’ve opened this as a draft PR to proceed with caution. I would appreciate a thorough review of the SQL and migration files to ensure there are no issues.

[alfredzimmer]

Links to #171

[AD1938]

Please include information about:

1. a brief overview of what the code is doing
2. how you tested your changes (so that I can test on my side), with some evidence (screenshots / logs / screen recordings)

This will make it easier to review, thanks :)

[alfredzimmer]

This PR fixes an issue where classes with multiple locations were not being parsed and also adds the feature that the generated ics file would contain location information for respective classes.

Changes

1. Updated parse.go to handle multiple locations for a single class.
2. Added a location column to the user_schedule table to persist the data.
3. Updated the export logic to extract location from database to ics file.
4. Added script/test_calendar_export.sh to generate ics file for testing.

Testing

1. Run make test to see unit test for parse_test.go and calendar_test.go.
2. Run script/test_calendar_export.sh after dev env is set. And try loading the ics file at the working directory into arbitrary calendar software.

[alfredzimmer]

On my side, the imported ics file would look like this in the screenshot.

[AD1938]

QA LGTM, will code review after.

I also tested it by running the frontend locally as well and use the calendar export button, I feel script/test_calendar_export.sh might be redundant?

Also, I have never experienced a class to have multiple locations, has that happened to you? I would like to see how this looks like on Quest. Thank you.

[alfredzimmer]

I'm fine with removing the test_calendar_export.sh if you think so.

I added this feature for multiple classrooms because the previous version handles the situation and also there's a test case for that in the codebase. Tho that has never happened to me.

[AD1938]

I'm fine with removing the test_calendar_export.sh if you think so.

I added this feature for multiple classrooms because the previous version handles the situation and also there's a test case for that in the codebase. Tho that has never happened to me.

for "the previous version" do you mean this PR?

[alfredzimmer]

In flow/api/parse/schedule/testdata/schedule-normal.txt there is a class with MC 4064 DWE 2527 as classrooms. So I wrote the parser that way to handle this situation.

[edwinzhng]

I'm fine with removing the test_calendar_export.sh if you think so.

I added this feature for multiple classrooms because the previous version handles the situation and also there's a test case for that in the codebase. Tho that has never happened to me.

Agree with removing the test script, feels redundant to commit that to the codebase when we already have unit tests for the calendar generation

For multiple classrooms, yeah we used to have that a lot (6 years ago) but I don't know what the situation is now. If it's not that much of a hassle I would prefer to continue handling that case just in case

[AD1938]

looks great!