Allow for adding annotations to service

[hgibs]

While completing an install on my cluster I had the need to use annotations on the service. The helm chart was missing that aspect so I added it.

Fixes: Allows for adding annotations to services (no pre-existing issue).

Using this config snippet in the values-local.yaml:

service:
  type: LoadBalancer
  annotations:
    io.cilium/lb-ipam-ips: "172.23.0.8"
    tailscale.com/expose: "true" 

And then running helm template --create-namespace --namespace zulip -f ./values-local.yaml zulip . > templated.yaml

results in this output (rest of yaml omitted for brevity):

---
# Source: zulip/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: zulip
  labels:
    helm.sh/chart: zulip-1.11.54
    app.kubernetes.io/name: zulip
    app.kubernetes.io/instance: zulip
    app.kubernetes.io/version: "11.5-2"
    app.kubernetes.io/managed-by: Helm
  annotations:
    io.cilium/lb-ipam-ips: 172.23.0.8
    tailscale.com/expose: "true"
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: zulip
    app.kubernetes.io/instance: zulip

Running with this config (without annotations):

service:
  type: LoadBalancer

and running the same command, results in this service yaml:

---
# Source: zulip/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: zulip
  labels:
    helm.sh/chart: zulip-1.11.54
    app.kubernetes.io/name: zulip
    app.kubernetes.io/instance: zulip
    app.kubernetes.io/version: "11.5-2"
    app.kubernetes.io/managed-by: Helm
  annotations:
    {}
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: zulip
    app.kubernetes.io/instance: zulip

I am using this fork in a running installation using annotations as well.

Edits to my comments, especially in the example are welcome! This is a fairly straightforward fix and I tried to mirror how annotations work for the ingress.

Self-review checklist

• Self-reviewed the changes for clarity and maintainability
  (variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

• Explains differences from previous plans (e.g., issue description).
• Highlights technical choices and bugs encountered.
• Calls out remaining decisions and concerns.
• Automated tests verify logic where appropriate. (N/A)

Individual commits are ready for review (see commit discipline).

• Each commit is a coherent idea.
• Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

• Visual appearance of the changes.
• Responsiveness and internationalization.
• Strings and tooltips.
• End-to-end functionality of buttons, interactions and flows.
• Corner cases, error conditions, and easily imagined bugs.