feat: implement error-conditions

[kaessert]

We are using aiven-operator in an argocd-setup where we heavily rely on status conditions for synchronization and monitoring purposes. After evaulating the operator we found two major issues:

• In the case of failed preconditions, actual conditions never get written to kube-api
• In the case of error, no condition is ever set on kube-api level to indicate that something failed

Changes this PR introduces:

1. defer function was moved to a higher level in order to consistently trigger status-updates
2. new status conditions in the case of an error during find, create, update, delete were added
3. a new event was introduced sent out when preconditions are not met

This pr builds on top of some of the work done in #101
I was reading the full discussion there as well as on the issue and i might not that i think it is not a good idea
to remove status conditions in the case the status resolves. I don't find this a standard practice in the whild and there
are good reasons for it. We would only hide that an error happened in the past and for everyone looking at the current
object it would still be clear that the object is healthy because we have a newer status condition then signaling that
the current state is indeed healthy.

Resolves: #66

[Serpentiel]

hey, @atarax! 👋

thank you for your contribution!

it looks like a major change to me, so I'd like to ask @byashimov to check it out

[byashimov]

Hey @atarax
Thanks for the contribution.
There are known issues with the events. In particular, the RUNNING event might be lost by some reason. Moving the defer to the beginning of the function did not work for me. There must be some race or something. Though, I will carefully test you PR, I believe this is not the end. It might require deeper changes.
And if I may ask, would you use crossplane solution instead of this operator if we had one?

[kaessert]

@byashimov thanks for the quick response! I have no issues with this version which were visible to me regarding events but i was mainly focused on the status conditions. Give it a try and if there is still a problem i can look into that. :)
Regarding crossplane-provider, i would really prefer using a provider instead of a full-fledged operator for many reasons. The most important ones are:

• obviously the whole backend with resolving dependencies, management policies doesn't need to be maintained in a second place and it's of course a lot more active and matrue
• ability to use crossplane compositions
• current operator has a pitfall in terms of security as it needs the secret to be present in the same namespace

I think it shouldn't be that hard to create a provider on the base what you already have :)

[byashimov]

lgtm