[BUG] FileChangeReloadStrategy doesn't deal properly with symlink changes

[rocketraman]

Describe the bug
In some environments (Kubernetes), a config file can actually be a chain of symlinks. When the ConfigMap backing the chain of symlinks changes, Kubernetes doesn't update the real file itself, but instead just changes the symlinks to point to a different file entirely.

In Kubernetes, this layout may look like this:

configfile -> ..data/configfile
 ..data -> ..2019_09_20_05_25_13.1
..2019_09_20_05_25_13.1/configfile
..2019_09_20_05_25_13.2/configfile

and when the backing ConfigMap changes, K8S creates a new timestamped directory containing the updated config file, points the ..data symlink to it, and then deletes the old timestamped directory.

To Reproduce
Create the directory structure shown above. Modify the ..data symlink to point to the .2 timestamped directory, containing a different version of configfile:

ln -sfn ..2019_09_20_05_25_13.2 ..data

The config should reload, but it does not.

Expected behavior
The watcher needs to follow the chain of symlinks up to the real file, and check if any of these symlinks have been changed in order to trigger a reload.

Additional context
I will submit a pull request for this.

[jdiazcano]

I just merged