General assembly: excuse passives (fixes #417)

[Trigary]

No description provided.

[kdmnk]

Nice! We have some test cases for general assemblies. Can you add one to test this behaviour? Add 3 users, 1 active 2 passive, make a general assembly and check the excusedUsers if its set properly.

If you want, we could also make some improvements with the excused users here:
The table where we collect them are called "general_assembly_user" but the naming should conclude something about exclusion. Make a migration to rename it.
And another thing came into my mind is that we should add a comment/reason for the exclusion, especially if we start adding users automatically. We have some examples for pivot attributes (roles, semester status) but a simple value is enough here. You can check https://laravel.com/docs/10.x/eloquent-relationships#retrieving-intermediate-table-columns.
Then you also need to get the value from the UI.
Or you can open a new issue for these.

[Trigary]

Thanks, I'll make the changes you mentioned.

I just saw #300 (which mentions that observers should be preferred), therefore I just pushed a commit that makes the necessary changes. Let me know if I misunderstood something and should undo the commit.

[kdmnk]

No it's good, I just did not want to say it as we you only used the "created" event here. Observers are best if you handle a lot of events there but at least now we are consistent.

[Trigary]

I made the requested changes :)

I made two separate database migrations, because I figured a table rename is disruptive enough to warrant its own migration file. Let me know if I should combine the migrations instead.

The way the localization is handled for the comment column is sub-ideal: the backend fills the database with a localized string based on the locale of the user who creates the general assembly. Instead of storing a localized string, we could add some sort of flag column that determines whether the contents of the comment column should be displayed as-is or if it should be used as a localization key. Let me know if the current solution is adequate or if I should do something differently.

[kdmnk]

LGTM. You can store the localization key and translate when you display it. It won't mess up custom values.