[ENH] Log client healthcheck

[HammadB]

Description of changes

Summarize the changes made by this PR.

• Improvements & Bug fixes
  • This change waits for a valid memberlist to be ready for the log client before marking the pod as ready
  • This should address the flakes that have started to occur after making tilt in CI come up faster when we decoupled docker builds from tilt up, which makes this path more likely
  • This mirrors the same path as the query executor
• New functionality
  • None

Test plan

They are not currently tests
How are these changes tested?

• Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Documentation Changes

None

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[propel-code-bot]

Add Log Client Healthcheck to Readiness Evaluation

This PR enhances the application's readiness and health check mechanism by introducing a check for the log client's readiness, specifically ensuring that the memberlist-based log client assigner is fully initialized before the pod is marked as ready. The changes propagate this readiness check through the relevant log abstraction layers and update health check API responses to report log client readiness alongside executor readiness. This addresses recent CI flakes that occurred after build pipeline optimizations, aligning log client readiness semantics with those already established for the query executor.

Key Changes:
• Introduced is_ready() to log abstraction and log client for readiness checks
• Healthcheck API struct now includes is_log_client_ready flag; logic updated to factor both executor and log client readiness
• ServiceBasedFrontend and InMemoryFrontend updated to report log client readiness
• HealthCheckResponse and its status_code computation updated to treat readiness as the conjunction of executor and log client
• Documentation and comments added to clarify readiness semantics

Affected Areas:
• Log system abstraction (GrpcLog, Log enums)
• Frontend service readiness/healthcheck (in_memory_frontend, service_based_frontend)
• API types (HealthCheckResponse)
• CI and startup readiness logic

This summary was automatically generated by @propel-code-bot