Set Creating and Deleting conditions close to Status().Update() calls

[negz]

Description of your changes

Relates to #285

This approach causes us to repeat ourselves a bit, but prevents issues like the above, where refactoring caused us to accidentally overwrite a pending status update that we hadn't committed.

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

I haven't yet.

[muvaf]

Need a few additions. The rest looks good to me but I think this fixes only one part of #285 . We still lose the status set in external.Create so we shouldn't close that issue.

[negz]

We still lose the status set in external.Create so we shouldn't close that issue.

Oh - I missed that. I didn't think we actually had any managed resources that modified status during Create (apart from setting the Creating status condition, which we now handle in the reconciler). Do you have an example of resources that do this? Now that I think about it I'm vaguely remembering some of the Azure resources recording operations there?

[muvaf]

I had not thought about Azure but yes and in fact, it could be showstopper since the creation process is being tracked with that ID. I was thinking about AWS, where the response of Create operation is stored in status, which in some cases is different than Describe, though I couldn't find an example now.

FWIW, there is this KEP by Tim Hockin that removes the litmus test of If I erased the whole status struct, would everything in it be reconstructed (or at least be reconstructible) from observation? So, status won't be treated as ephemeral as it used to be.