fix(consul-postgres-ha): generate Envoy bootstrap then exec, bypassing version check

Consul 1.19's `consul connect envoy` (without -bootstrap) tries to
exec envoy itself and rejects "Envoy version 1.30.x is not
supported" — the contrib-v1.30 image we use isn't on its
compatibility list. Going back to the original pattern:
`consul connect envoy ... -bootstrap > /tmp/envoy-X.json` to just
generate the JSON, then `exec envoy -c /tmp/envoy-X.json`. The
bootstrap config itself works fine; only the consul-launches-envoy
path enforces the version check. Restored the pattern for both the
webdemo and postgres sidecar Envoys, with a supervise loop that
re-bootstraps and restarts envoy if it ever exits.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: h4x3rotab

consul-postgres-ha/mesh-sidecar/entrypoint.sh

@@ -208,34 +208,50 @@ EOF
   # Wait for Connect CA to be able to mint leaf certs. Servers don't
   # need Envoy to form quorum (Raft RPC rides peer VIPs as plain TCP),
   # but workers can't start their sidecars until a server can issue.
+  # The leaf-cert API is HTTP-only — there is no `consul connect ca
+  # leaf` CLI subcommand (only get-config / set-config).
   log "waiting for connect CA to be ready..."
-  until consul connect ca leaf -service="${CLUSTER_NAME}" >/dev/null 2>&1; do
+  until curl -fsS "http://127.0.0.1:8500/v1/agent/connect/ca/leaf/${CLUSTER_NAME}" >/dev/null 2>&1; do
     sleep 2
   done
   log "connect CA ready"
 
-  # Webdemo Envoy supervise loop. Webdemo registers itself + a
-  # SidecarService block with port=21000 from its own entrypoint;
-  # consul connect envoy waits for that registration to land.
+  # Webdemo Envoy supervise loop. We use `consul connect envoy
+  # -bootstrap` to generate the JSON, then exec envoy ourselves; this
+  # bypasses Consul's Envoy version-compatibility check (Envoy 1.30
+  # bundled with the sidecar image isn't on Consul 1.19's supported
+  # list, but the bootstrap config is fine). Webdemo registers its own
+  # SidecarService block from webdemo/main.go; the bootstrap call
+  # blocks until that registration is in place.
   (
-    until consul connect envoy \
+    while true; do
+      if consul connect envoy \
             -sidecar-for="webdemo-${PEER_ID}" \
             -admin-bind="127.0.0.1:19000" \
-            >/dev/null 2>/dev/null; do
-      echo "[envoy-webdemo] waiting for webdemo sidecar registration..."
+            -bootstrap \
+            > /tmp/envoy-webdemo.json 2>/dev/null; then
+        envoy -c /tmp/envoy-webdemo.json -l info 2>&1
+      else
+        echo "[envoy-webdemo] waiting for webdemo sidecar registration..."
+      fi
       sleep 2
     done
   ) 2>&1 | prefix envoy-webdemo &
   ENVOYS+=("$!")
 
-  # Postgres Envoy supervise loop. The proxy-id is what we registered
-  # above; consul connect envoy bootstraps Envoy from that registration.
+  # Postgres Envoy supervise loop, same pattern. Bootstrap from the
+  # standalone connect-proxy registration above.
   (
-    until consul connect envoy \
+    while true; do
+      if consul connect envoy \
             -proxy-id="postgres-sidecar-${PEER_ID}" \
             -admin-bind="127.0.0.1:19001" \
-            >/dev/null 2>/dev/null; do
-      echo "[envoy-postgres] waiting for ca leaf..."
+            -bootstrap \
+            > /tmp/envoy-postgres.json 2>/dev/null; then
+        envoy -c /tmp/envoy-postgres.json -l info 2>&1
+      else
+        echo "[envoy-postgres] waiting for ca leaf / proxy registration..."
+      fi
       sleep 2
     done
   ) 2>&1 | prefix envoy-postgres &