Ingress per deployment?

So we recently refactored nginx-ingress to nginx-ingress-controller and nginx-ingress-services. I think we can take it a step further which will make the code a bit nicer in my opinion

Currently nginx-ingress-services contains a single Ingress, referring to each Service per Deployment that is exposed.

the ingress controller, however can actually support more than one Ingress at the same time, and it will listen to changes in all of them and merge them together. This would allow us to move the Service and Ingress files to their respective charts, meaning we don't need to specify externalPorts in multiple places (e.g. both in the nginz chart and in the nginx-ingress-services chart).

It also means people can deploy wire-server chart with an existing ingress-controller and things should 'just work'. Instead of having to configure the nginx-ingress-services chart with the same values that were already in wire-server

e.g. we would have

nginz
├── templates
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── secret.yaml
webapp
├── templates
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── secret.yaml

Instead of

nginz
├── templates
│   ├── configmap.yaml
│   ├── deployment.yaml
│   └── secret.yaml
webapp
├── templates
│   ├── configmap.yaml
│   ├── deployment.yaml
│   └── secret.yaml
nginx-ingress-services/
├── Chart.yaml
├── README.md
├── templates
│   ├── ingress.yaml  <-- contains duplicate port also present in `nginz` chart, contains duplicate port also present in `webapp` chart
│   ├── secret.yaml
│   └── service.yaml <-- contains duplicate port also present in `nginz` chart, contains duplicate port also present in `webapp` chart
└── values.yaml

This makes the configs a bit less spread out and will have less code duplication, which removes room for error when for example changing port numbers of a service

Thoughts?

Compare nginx-ingress-services/templates/ingress.yaml and service.yaml with the templates in the nginz and webapp charts. Start by tracing how each chart currently defines exposed services and ports, then determine whether chart-local resources can work with an existing ingress controller without duplicated values; done means the proposed layout and configuration behavior are agreed and consistently represented.