Adds E2E tests for event service

[Nydauron]

All tests should query one endpoint. Each endpoint should have a test under normal conditions, a test with insufficient perms (if applicable), and any other tests triggering any other errors that the endpoint can generate.

• [x] GET /event/favorite/
• [x] POST /event/favorite/
• [x] DELETE /event/favorite/
• [x] GET /event/filter/
  • [x] Test all query parameters
• [x] GET /event/{id}/
• [x] DELETE /event/{id}/
• [x] POST /event/
• [x] PUT /event/
• [x] GET /event/
• [x] GET /event/code/{id}/
• [x] PUT /event/code/{id}/
• [x] POST /event/checkin/
• [x] POST /track/
• [x] GET /track/event/{id}/
• [x] GET /track/event/{id}/

These tests are coded up to expect new appropriate error codes instead of the standard always 500 on failure.

[Nydauron]

We might want to consider not doing deep equals with ApiErrors, since message content changing will then require updating a test, which might be more of a hassle. It doesn't hurt that much though, so it's more just food for thought.

The API errors that get returned are typically static strings, so checking these will only help reinforce that we are getting the intended error message. And yeah, while we would need to edit the expected error in the tests, it should be a quick change and rather detectable.

[Timothy-Gonzalez]

We might want to consider not doing deep equals with ApiErrors, since message content changing will then require updating a test, which might be more of a hassle. It doesn't hurt that much though, so it's more just food for thought.

The API errors that get returned are typically static strings, so checking these will only help reinforce that we are getting the intended error message. And yeah, while we would need to edit the expected error in the tests, it should be a quick change and rather detectable.

Alright, sounds good!