fix: fail on request errors for triggering retry

[merll]

This PR replaces all instances of utils.doApiCall, which adds errors to a list but never raises them. This causes rejected requests to external APIs to get logged, but never retried. As a consequence, the operator will on a temporary failure (e.g. connection glitch) never reconcile fully until it is restarted.

The only additional functionality of this function wrapper is that it passes over 409 errors (conflict) which might not be the most sensible thing to do in all situations. Where appropriate, the retry after a failed request (i.e. due to a race condition of two operator instances) with this particular error should come to the same result – otherwise it is more likely that the operator needs to be refined for such cases instead of suppressing the error.

For reducing the chance of race conditions, some more functions in role setup are awaited, and a single connection / api object is used during one update cycle. The update cycle of user groups has been consolidated into one function, and some unused or overly nested function calls have been removed.

In that regard, some objects are now being checked if they need updating (client, realm, users) before posting an update request. This should also lead to less errors (e.g. a known issue with duplicate redirect URLs), which seem to be a result of the Keycloak API not being able to handle nested object updates in all cases. There might still be potential in extending this approach to further objects.

[merll]

@ferruhcihan I reproduced the issue that you mentioned. It was actually the same error that usually leads to the user not getting assigned, just that it was logged but never thrown again. Unfortunately it still does not resolve by itself, so I am checking on it.