remove time logging on the prom/remote/write endpoint

[BertHartm]

The logging currently kicks in with force if there's any issues with m3, but we can get all the information from prometheus_remote_storage_sent_batch_duration_seconds_bucket in prometheus, so removing the loggging cuts down on noise and potential side effects in case of issues.

[BertHartm]

I was hoping this would improve performance under load too, but it seems to have no immediate effect on that.

[arnikola]

I think this may be slightly better served by making response time logging a noop unless a debug flag is supplied, possibly with a param to determine the logging threshold.

I'm not sure we currently really do anything with these logs but will try and double check if that would be a decent approach in the morning

[arnikola]

Talking with @robskillington decided to drop the logging from the write path entirely, and maybe consider taking a flag to turn it on for the read side only, so this should be good 👍

[nikunjgit]

One thing to wonder here though is that when write path is not working well, we won't really have a way anymore to figure that out. Earlier, once you started seeing those logs, you can get an early warning.

[BertHartm]

I've been graphing prometheus_remote_storage_sent_batch_duration_seconds_bucket which gives me a much more detailed signal. I've been keeping a separate dashboard from the m3db node dashboard for prometheus remote write stats, but I could add a row to that dashboard in a PR if it would be helpful.