Make UseAsync=true by default

[ezgidemirel]

Signed-off-by: ezgidemirel ezgidemirel91@gmail.com

Description of your changes

In this PR, we're changing default UseAsync value to true. Details can be found here.

Fixes #

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable to ensure this PR is ready for review.
• Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

Consumed it in provider-aws and applied following manifests. Checked AWS console to make sure there is only one NAT gateway exists.

---
apiVersion: ec2.aws.upbound.io/v1beta1
kind: NATGateway
metadata:
  name: ezgi-aws-cluster-nat-a
spec:
  forProvider:
    allocationIdRef:
      name: ezgi-aws-cluster-nat-eip-a
    region: us-west-2
    subnetIdRef:
      name: ezgi-aws-cluster-subnet-public-a
    tags:
      ResourceType: natgateway
      Name: ezgiAWSClusterNatGateway1
---
apiVersion: ec2.aws.upbound.io/v1beta1
kind: EIP
metadata:
  name: ezgi-aws-cluster-nat-eip-a
spec:
  forProvider:
    region: us-west-2
    tags:
      ResourceType: elastic-ip
      Name: ezgiAWSClusterNatEip1
---
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Subnet
metadata:
  name: ezgi-aws-cluster-subnet-public-a
spec:
  forProvider:
    availabilityZone: us-west-2a
    cidrBlock: 10.0.101.0/24
    region: us-west-2
    mapPublicIpOnLaunch: true
    tags:
      ResourceType: subnet
      kubernetes.io/role/elb: "1"
      Name: ezgiAWSClusterPublicSubnet1
    vpcIdRef:
      name: ezgi-aws-cluster
---
apiVersion: ec2.aws.upbound.io/v1beta1
kind: VPC
metadata:
  name: ezgi-aws-cluster
spec:
  forProvider:
    cidrBlock: 10.0.0.0/16
    enableDnsHostnames: true
    enableDnsSupport: true
    region: us-west-2
    tags:
      ResourceType: vpc
      Name: ezgiAWSClusterVPC

[muvaf]

@ezgidemirel I'd like us to make sure that the callback does trigger a new reconciliation. Could you validate that? It could be via testing if time-to-readiness changes for a resource whose creation is quick like AWS VPC and one whose creation takes long like EKS cluster.

[ezgidemirel]

Before: VPC resource synced after 37 seconds and became ready after 55 seconds.

apiVersion: ec2.aws.upbound.io/v1beta1
kind: VPC
metadata:
  annotations:
    crossplane.io/external-create-pending: "2022-09-02T16:07:06+03:00"
    crossplane.io/external-create-succeeded: "2022-09-02T16:07:06+03:00"
    crossplane.io/external-name: vpc-0645fa0f16f782abf

After VPC resource synced after 32 seconds and became ready after 51 seconds.

apiVersion: ec2.aws.upbound.io/v1beta1
kind: VPC
metadata:
  annotations:
    crossplane.io/external-create-pending: "2022-09-02T16:00:54+03:00"
    crossplane.io/external-create-succeeded: "2022-09-02T16:00:54+03:00"
    crossplane.io/external-name: vpc-062567dd1276cf3c9

Couldn't catch with annotations though :)

EKS cluster is already configured as async. So, I don't expect any significant time differences for it.

[muvaf]

This is quite a change especially in AWS but that doesn't mean we can't do it. Let's keep an eye on the differences like debugging experience where we'll see two more conditions in most resources.

@ezgidemirel Thank you for pushing for the better!