YamlFileConfigurationService fails to start health check monitors

[mikkokar]

Summary

This PR fixes a race condition in YamlFileConfigurationService that sometimes prevents it from being able to start health check monitoring services.

Also, yaml file configuration service now adds a backend service app name in the health check monitoring service name. This is useful as the application name will show up in possible error messages in case other bugs will surface in future.

User impact

Especially, this bug affects deployments several YamlFileConfigurationService providers (more than one). When the health check monitoring service is not started, the relevant HostProxy objects for the origin are not added to the load balancing group, and therefore they are always unreachable.

The issue doesn't affect, or is highly unlikely to affect deployments with only one YamlFileConfigurationService provider.

Root cause

Styx object database is a lockless concurrent in-memory database for storing routing/provider/etc objects. Its compute method takes a lambda that provides a new styx object that is stored in the database. The compute lambda action must idempotent because the database will call it again if it detects a concurrent modification to the database.

But YamlFileConfigurationService was not idempotent. It attempted to start the health check monitoring service in this lambda callback. Therefore, a retry during the concurrent modification caused the health check monitoring service to be started again, thus resulting in an IllegalStateException.

Fixed this by caching the return value from the lambda callback. Consider this as a work around until I figure out something better.