fix(resource-detector): properly detect zone on AppEngine standard

[aabmass]

Fixes #655

It turns out GAE standard environment's metadata server returns a zone string like projects/myproject/zones/us15. ut integration tests only run on AppEngine flex not standard so this wasn't caught 🙁. Here are HTTP logs I printed out from a sample app:

{
  "jsonPayload": {
    "message": "gaxios metadata request",
    "responseData": "projects/<project>/zones/us15",
    "requestUrl": "http://169.254.169.254/computeMetadata/v1/instance/zone"
  },
  "resource": {
    "type": "gae_app",
    "labels": {
      "zone": "us15",
      "version_id": "20240503t222051",
      "project_id": "otel-starter-project",
      "module_id": "default"
    }
  }
}

I updated the tests and manually tested a sample app on GAE standard writing metrics:

---

I think this bug is also affecting all other resource detectors e.g. Go's impl that this was copied from

[psx95]

Summary for this issue in other language detectors:

• As mentioned in the PR description, the Go resource detector does seem to suffer from the same bug.

• The Java Resource detector implementation does not seem to have this issue.

• The Python resource detector does not seem to support GAE. Is this correct ?

[psx95]

Nit: The console.log statements could be removed.

The change looks good.

[aabmass]

• The Java Resource detector implementation does not seem to have this issue.

I think it does have the issue. This test doesn't provide the slash separated string for GAE standard and the detector just returns the zone directly

[psx95]

• The Java Resource detector implementation does not seem to have this issue.

I think it does have the issue. This test doesn't provide the slash separated string for GAE standard and the detector just returns the zone directly

We might need to add a test to prevent regression, but going by the implementation of metadataConfig.getZone(), it does not look like there would be an issue as it is similar to what is being done in this fix.

[aabmass]

We might need to add a test to prevent regression, but going by the implementation of metadataConfig.getZone(), it does not look like there would be an issue as it is similar to what is being done in this fix.

Here is a test update GoogleCloudPlatform/opentelemetry-operations-java#341 thanks