Explicitly fetch client in TestAccResourceTelemetryServiceRegistryEntry() for env side effect

[chrismarget-j]

Test relies on env var APSTRA_URL which doesn't get set without explicit client fetch ... which is something we usually do for per-subtest version constraint checking.

This test has no version constraint tests, and didn't fetch the client from the HCL test config file, rendering the test inoperable without explicit setting.

This PR adds a client fetch (like the others have) for the side-effect of setting the environment variable.

Closes #894

[bwJuniper]

still seems to be failing for me resource_telemetry_service_registry_entry_test.go:245: Step 1/2 error: Error running apply: exit status 1

    Error: Provider produced inconsistent result after apply
    
    When applying changes to apstra_telemetry_service_registry_entry.test,
    provider "provider[\"registry.terraform.io/hashicorp/apstra\"]" produced an
    unexpected new value: .application_schema: was
    cty.StringVal("{\"properties\":{\"key\":{\"properties\":{\"authenticated_vlan\":{\"type\":\"string\"},\"authorization_status\":{\"type\":\"string\"},\"fallback_vlan_active\":{\"enum\":[\"True\",\"False\"],\"type\":\"string\"},\"port_status\":{\"enum\":[\"authorized\",\"blocked\"],\"type\":\"string\"},\"supplicant_mac\":{\"pattern\":\"^([0-9A-Fa-f]{2}[:-]){5}([0-9A-Fa-f]{2})$\",\"type\":\"string\"}},\"required\":[\"supplicant_mac\",\"authenticated_vlan\",\"authorization_status\",\"port_status\",\"fallback_vlan_active\"],\"type\":\"object\"},\"value\":{\"description\":\"0
    in case of blocked, 1 in case of
    authorized\",\"type\":\"integer\"}},\"required\":[\"key\",\"value\"],\"type\":\"object\"}"),
    but now cty.StringVal("{\"properties\": {\"key\": {\"properties\":
    {\"authenticated_vlan\": {\"type\": \"string\"}, \"authorization_status\":
    {\"type\": \"string\"}, \"fallback_vlan_active\": {\"enum\": [\"True\",
    \"False\"], \"type\": \"string\"}, \"port_status\": {\"enum\":
    [\"authorized\", \"blocked\"], \"type\": \"string\"}, \"supplicant_mac\":
    {\"pattern\": \"^([0-9A-Fa-f]{2}[:-]){5}([0-9A-Fa-f]{2})$\", \"type\":
    \"string\"}}, \"required\": [\"authenticated_vlan\",
    \"authorization_status\", \"fallback_vlan_active\", \"port_status\",
    \"supplicant_mac\"], \"type\": \"object\"}, \"value\": {\"description\": \"0
    in case of blocked, 1 in case of authorized\", \"type\": \"integer\"}},
    \"required\": [\"key\", \"value\"], \"type\": \"object\"}").
    
    This is a bug in the provider, which should be reported in the provider's own
    issue tracker.