feat(remove): remove deprecated providerRef

[haarchri]

Description of your changes

remove the very long deprecated providerRef - from time to time we see questions regarding providerRef - because this field is available in all providers

did we have anything i am not aware of why we want to use this field ?

few examples:
https://marketplace.upbound.io/providers/upbound/provider-aws-accessanalyzer/v0.37.0/resources/accessanalyzer.aws.upbound.io/Analyzer/v1beta1#doc:spec-providerRef

https://marketplace.upbound.io/providers/upbound/provider-azure-alertsmanagement/v0.34.0/resources/alertsmanagement.azure.upbound.io/MonitorActionRuleActionGroup/v1beta1#doc:spec-providerRef

https://marketplace.upbound.io/providers/upbound/provider-gcp-activedirectory/v0.34.0/resources/activedirectory.gcp.upbound.io/Domain/v1beta1#doc:spec-providerRef
https://marketplace.upbound.io/providers/upbound/provider-terraform/v0.8.0/resources/tf.upbound.io/Workspace/v1beta1#doc:spec-providerRef

https://marketplace.upbound.io/providers/crossplane-contrib/provider-aws/v0.41.1/resources/acm.aws.crossplane.io/Certificate/v1beta1#doc:spec-providerRef

Fixes #

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

[negz]

AFAIK The only reason it's still there is that removing it would be a breaking API change.

I agree that it's been deprecated long enough that we should be fine to remove it - I'm not aware of any v1 APIs it would affect. Any providers that picked up the change would need to communicate it well.

[negz]

Are there any other deprecated fields that we want to remove at the same time?

[haarchri]

Have no other field in my mind -

[negz]

@haarchri I had a look. There's a few others that are due for deprecation, e.g.:

• spec.deletionPolicy (will be deprecated by spec.managementPolicies)
• spec.writeConnectionSecretToRef (will be deprecated by spec.publishConnectionDetailsTo)

Given that we've waited this long to remove spec.providerRef I could be convinced to wait until management policies and secret stores are GA so we can remove all three deprecated fields at once. Feels like it might be better to batch up potentially breaking changes.

That said, I don't feel strongly. I suspect that removing spec.providerRef will not affect anyone at this point, unlike the other two examples.

[turkenh]

While I like the idea of batching multiple at once, I believe the deprecation of providerRef could be much smoother compared to the other two as it is not prevalent as others, and it has been a long time since it was replaced with providerConfigRef.

So, I prefer to merge this and batch the other two together.