Fix relogin logic

[LuisDuarte1]

There was an issue with the relogin logic, that breaks almost every fetcher that depends on the student number on the app.

When the user login info is saved, the username is saved as upxxxxxxxxx being x digits. When the app loads, it loads a fake session on SessionProvider.restoreSession() with username being the one loaded from user preferences (so therefore it loads upxxxxxxxxx) , when NetworkRouter.getWithCookies is called for the first time, it will try to do the request but it will know that this session is not valid (because on app start, it will have no cookies) and try to relogin. The cookies are copied from the newSession to the session that was given as an argument. The problem is that, the username stays the same so in the upxxxxxxxxx form, and every api to sigarra that needs a student number expects only the number part, breaking almost all fetchers.

Review checklist

• Terms and conditions reflect the current change
• Contains enough appropriate tests
• If aimed at production, writes a new summary in whatsnew/whatsnew-pt-PT
• Properly adds an entry in changelog.md with the change
• If PR includes UI updates/additions, its description has screenshots
• Behavior is as expected
• Clean, well-structured code

[LuisDuarte1]

The current fix, is just to copy the newSession username everytime, but maybe the relogin logic needs a refactor, because on app load if there isn't a session we shouldn't create a fake one because it's prone to errors like this one

[bdmendes]

Awesome, good catch

[bdmendes]

@LuisDuarte1 If you want to, please create an issue about the refactor. I think we should try to make an enum with pattern matching: user that can have up or only numbers.