NetworkPolicies: Handle case where an Ingress routes to an ExternalName Service (#456)

[g-linville]

re: #456

Using a router and links, it is possible to expose a port in a service in a different namespace than the namespace in which the corresponding Ingress lives. Here is an example:

containers: "two": {
  image: "nginx:latest"
  ports: "80/http"
  files: {
    "etc/nginx/conf.d/default.conf": """
    server {
      listen 80;
      server_name localhost;
      location /two {
        return 200;
      }
    }
    """
  }
}

Run the above Acornfile: acorn run --name two .

services: {
  one: {
    container: "nginx-one"
    ports: ["80/http"]
    default: true
  }
}

routers: default: routes: {
  "/one": "one:80"
  "/two": "two:80"
}

containers: {
  "nginx-one": {
    image: "nginx:latest"
    ports: "80/http"
    files: {
      "/etc/nginx/conf.d/default.conf": """
      server {
        listen 80;
        server_name localhost;
        location /one {
          return 200;
        }
      }
      """
    }
  }
}

Run the above Acornfile and link it to the container from the previous one: acorn run --name one --link two:two .

This will create an Ingress in one's namespace that routes to an ExternalName Service, which then resolves to a ClusterIP service in two's namespace. I wasn't accounting for this scenario before, so these changes deal with that.

Unfortunately I also had to add a finalizer in here. Since we sometimes create NetworkPolicies in namespaces outside where the owning Ingress lives, if the app that created the Ingress is removed (in this example, acorn rm one), the namespace for the app might delete too quickly, and the NetworkPolicy in the other namespace (two's namespace in this example) will get left behind. The finalizer ensures that the NetworkPolicy gets cleaned up properly.

Checklist

• The title of this PR would make a good line in Acorn's Release Note's Changelog
• The title of this PR ends with a link to the main issue being address in paranthesis, like: This is a title (#1216). Here's an example
• All relevant issues are referenced in the PR description. NOTE: don't use GitHub keyworkds that auto-close issues
• Commits follow contributing guidance
• Automated tests added to cover the changes. If tests couldn't be added, an explanation is provided in the Verification and Testing section
• Changes to user-facing functionality, API, CLI, and upgrade impacts are clearly called out in PR description
• PR has at least two approvals before merging (or a reasonable exception, like it's just a docs change)

[cjellick]

just not sure if you need the deleteTimestamp check anymore

Made the changes - not sure how to mark this as resolved?