feat: error checking for initial API token call

[MrGiga]

Description

If the API token is invalid or expired, the current implementation does not return that error to inform the end user. This implementation adds error checking, returns that error and then does not continue. This should make debugging much easier compared to it's current state. From my research there are two possible error formats.

First error response: 401 unauthorized
{"message":"401 Unauthorized"}

Second possible error response: Token has expired
{"error":"invalid_token","error_description":"Token is expired. You can either do re-authorization or token refresh."}

Migrations required

None

Verification

Provide a bad or expired API token to the module. It should fail and output the reason for failure.

[github-actions]

Hey @MrGiga! 👋

Thank you for your contribution to the project. Please refer to the contribution rules for a quick overview of the process.

Make sure that this PR clearly explains:

• the problem being solved
• the best way a reviewer and you can test your changes

With submitting this PR you confirm that you hold the rights of the code added and agree that it will published under this LICENSE.

The following ChatOps commands are supported:

• /help: notifies a maintainer to help you out

Simply add a comment with the command in the first line. If you need to pass more information, separate it with a blank line from the command.

This message was generated automatically. You are welcome to improve it.

[MrGiga]

Code is slightly incomplete due to the following:

1. Is there specific semantics that the error output needs to follow?
2. What should be outputted to cover scenario where token is null and there is no message or error_description? Currently it just continues.

[kayman-mk]

Code is slightly incomplete due to the following:

1. Is there specific semantics that the error output needs to follow?
   No. It's fine as it is.

2. What should be outputted to cover scenario where token is null and there is no message or error_description? Currently it just continues.
   I think, we ignore this for now, as the GitLab API specification says, that this is the format of error messages. So we can expect an error message. By the way: Good job to include the error_description as well!

https://docs.gitlab.com/ee/api/rest/#sudo
https://docs.gitlab.com/ee/api/rest/#data-validation-and-error-reporting

[kayman-mk]

Thanks for contributing. This makes the debugging of the registration process easier.