Upjet shouldn't generate types with float fields

[negz]

What happened?

In crossplane-contrib/provider-upjet-gcp#623 various fields that appear to really be integers (e.g. port) are generated with type *float64. This led to a request to add paved.GetFloat() - some context and discussion in crossplane/crossplane-runtime#778.

You're not supposed to use floats in Kubernetes APIs. From https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#primitive-types:

Avoid floating-point values as much as possible, and never use them in spec. Floating-point values cannot be reliably round-tripped (encoded and re-decoded) without changing, and have varying precision and representations across languages and architectures.

See for example https://github.com/kubernetes-sigs/json, which deserializes JSON numbers into int64 where possible.

How can we reproduce it?

Take a look at the generated types in crossplane-contrib/provider-upjet-gcp#623.

[rickard-von-essen]

Guessing this is the code part that is the root of this (with a comment about the problem by @turkenh)

upjet/pkg/types/conversion/tfjson/tfjson.go

Lines 230 to 233 in a18bd41

	case typ.Equals(cty.Number):
	// TODO(turkenh): Figure out handling floats with IntOrString on type
	// builder side
	return schemav2.TypeFloat

Relevant parts of config/schema.json for google_redis_cluster in provider-upjet-gcp.

"discovery_endpoints": {
  "type": [
    "list",
    [
      "object",
      {
        "address": "string",
        "port": "number",