adding fleet_endpoint to integrations_server

[sholzhauer-es]

Add a property to the datasource of ec_deployment to directly get the fleet endpoint.

Description

Related Issues

#875

Motivation and Context

It allows a deployment to directly reference data.ec_deployment.stack.integrations_server.fleet_endpoint instead of having to dynamically build it from available properties (see issue)

How Has This Been Tested?

1. first determined the api response (focussed on int.server):

...
"integrations_server" : [
      {
        ...
        "info" : {
          ...
          "metadata" : {
            ...
            "ports" : {
              "http" : 80,
              "https" : 443,
              "transport_passthrough" : 9400
            },
            "services_urls" : [
              {
                "service" : "fleet",
                "url" : "https://hosted-sholzhauer.fleet.us-west2.gcp.elastic-cloud.com"
              },
              {
                "service" : "apm",
                "url" : "https://hosted-sholzhauer.apm.us-west2.gcp.elastic-cloud.com"
              }
            ]
          },
          ...
        }
      }
    ]
...

which showed the availability of the endpoint

2. determined how the endpoint (http/https) was currently build
3. added the code in the commit
4. ran make build
5. copied the binary from /bin/ to my test directory
6. ran terraform init -upgrade and terraform apply in test directory
7. got the fleet_endpoint in the output

Test template

referencing a test cluster of mine

terraform {
  required_providers {
    ec = {
      source = "elastic/ec"
      version = ">= 0.0.1"
      #source = "terraform-provider-ec"
    }
  }
}

variable "apikey" {}
variable "region" { default = "gcp-us-west1" }

provider "ec" {
  apikey = var.apikey  
}

data "ec_deployment" "example" {
  id = var.cluster_id
}

output "fleet" {
  value = data.ec_deployment.example
}

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (improves code quality but has no user-facing effect)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation

Readiness Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed