quota: throughput racy enforcement bug fixes

[bom-d-van]

Three changes are made, but the most important one is quota: fix a race condition bug in trieIndex.applyQuotas. The other two commits are by-products of debugging the racy applyQuotas.

quota: fix a race condition bug in trieIndex.applyQuotas

the current quota config file is last-match-wins, and with heavy concurrent
quota enforcement, go-carbon should only update quota info per node once,
otherwise it risks of having confusing and incorrect quota enforcement.

for example, suppose we have the following quota configs:

    [sys.*]
        throughput = 1024
    [sys.app]
        throughput = 4096

if sys.app is updated twice using top down order in the quota config file, there
is a window that sys.app would have a quota with throughput of 1024, and if the
namespace happen to be receiving more than 1024 data points during that window,
it would trigger incorrect throttling.

TODO: with updateChecker, it's also straightforward now to support
first-match-wins in quota config file, but we would have to introduce a new
flat to ask for it for backward compatibility.

quota: delay throughput counter update in trieindex.throttle

When throughput quota usage might be exhausted in a child rule, in the previous implementation,
the throughput counter would be updated immediately after the check, this might lead to over-accounting
for parent quota configs.

The comment changed the implementation to only update the counter if the traffic is confirmed
to be within quota consumption.

At the same time, go-carbon also makes sure to report throttled data points for soft throughput quota
enforcement (i.e. with "none" dropping policy).

quota: refactor throughputUsagePerNamespace usage/quota tracking and enforcement

The previous implementation has a racy update of throughputUsagePerNamespace.resetAt and dataPoints
that might potentially lead quota over-enforcement. This commit addess it by wrapping them in one
struct with atomic updates. The new tradeoff is under-enforcement during counter reset, a better
tradeoff imo. more details could be found in the commit.

[bom-d-van]

note: need to add a few tests for this PR in a separate one, it's only tested on our production and it seems to be working.

[bom-d-van]

note: also included some minor changes for deep source warning and debugging code cleanup.