metrics re-arch

Butler has 5 phases

with the simplified decision flow of....
If 200 then set metrics & set LKG
If timeout then set metrics (if timeout_ok = false) & leave the files on disk (do not delete)
If !200 then set metrics and restore LKG to disk

butler_
1. connection to the remote file store, could be S3/http etc
_remote_status{file="myfile} = return code of remote, 200 for http, not sure for s3
_remote_time{file="myfile} = timestamp of last time we got the file

Phase 1 will happen every interval, so we can use timestamps, phases below are not guanteed to happen every interval, only if the files changes, so we cannot use timestamps for alerting....

2. config parsing
_cfg_mustache{file="myfile} = 0 or 1
_cfg_render{file="myfile,method="yml|json|text} = 0 or 1

3. write files to disk
_write{file="myfile} = 0 or 1

4. reload config
_reload_status{manager="myman"} = return code when reloading, 0 for timeout
_reload_time{manager="myman"} = timestamp of last attempted reload (be it fail, succeed or timeout)

5.
_lkg{manager="myman"} = timestamp of the when the last known good was stored.

No files, tests, or entry points are named. Start by locating Butler's five phases and current metrics implementation, then compare them with the listed 200, timeout, and non-200 decision flows. Done means the metric names, labels, status values, and timestamps are defined for each listed outcome.

Written by the indexing model from the issue text.