fix: Bug #58523 - Add suitable startup probe for LDAP secondary servers

[charith-competa]

Problem

Secondary LDAP servers were using a TCP-based startup probe that only checked if port 389 was listening, not if replication had completed. This could cause secondary servers to receive traffic before replication data was available, leading to errors when clients queried data that hadn't been replicated yet.

Solution

• Added startupProbeSecondary configuration with exec-based probe
• Probe queries base DN to verify LDAP is responding and data is accessible
• Updated statefulset-secondary.yaml to use startupProbeSecondary with coalesce fallback to default startupProbe
• Increased failureThreshold to 30 to allow sufficient time for initial replication to complete

Changes

• helm/ldap-server/values.yaml: Added startupProbeSecondary configuration with exec command that queries base DN
• helm/ldap-server/templates/statefulset-secondary.yaml: Updated startupProbe to use startupProbeSecondary if defined, otherwise fallback to default

Testing

• Verified Helm template renders correctly with exec command for secondary servers
• Confirmed primary servers still use default tcpSocket probe (unchanged)
• Pattern matches existing readinessProbePrimary exec-based probe approach

Related

• Bug #58523