Add getFeeStats method

[2opremio]

What

Add getFeeStats method, with the following response data structure:

type GetFeeStatsResult struct {
	SorobanInclusionFee FeeDistribution `json:"sorobanInclusionFee"`
	InclusionFee        FeeDistribution `json:"inclusionFee"`
	LatestLedger        uint32          `json:"latestLedger"`
}

type FeeDistribution struct {
	Max              uint64 `json:"max,string"`
	Min              uint64 `json:"min,string"`
	Mode             uint64 `json:"mode,string"`
	P10              uint64 `json:"p10,string"`
	P20              uint64 `json:"p20,string"`
	P30              uint64 `json:"p30,string"`
	P40              uint64 `json:"p40,string"`
	P50              uint64 `json:"p50,string"`
	P60              uint64 `json:"p60,string"`
	P70              uint64 `json:"p70,string"`
	P80              uint64 `json:"p80,string"`
	P90              uint64 `json:"p90,string"`
	P95              uint64 `json:"p95,string"`
	P99              uint64 `json:"p99,string"`
	TransactionCount uint32 `json:"transactionCount,string"`
	LedgerCount      uint32 `json:"ledgerCount"`
}

It includes extra fields with respect to #114 (a global latestLedger fieldand a count` field in each distribution, it indicates how many fees were included to compute it).

We can, optionally also include the initial ledger used for each distribution if that's interesting (which, together with the global latestLedger field, will tell the user what ledger window was used for each distribution).

Why

Closes #114

Known limitations

N/A

[2opremio]

This is still untested but created early to gather feedback.

@tamirms I would like to know your opinion on the implementation. Unlike Horizon (which uses Postgres to compute the stats :S), we do everything in Go and book-keep an in-memory data structure. The juicy part is feewindow.go

@janewang Thoughts about the API?

[tamirms]

@2opremio in-memory approach makes sense to me especially considering we sample at most 50 ledgers

[janewang]

I like the idea of fromLedger and latestLedger. I think it is helpful and more transparent on the fee calculation for the end user.

For count is a great idea but I think you mean the sample size for the statistic distribution. I think maybe size is an appropriate name. When we say count I also think it could be the count of number of ledgers. Wdyt? cc @sydneynotthecity Please weigh in on naming convention for sample size.

[2opremio]

@janewang how about feeCount?

[2opremio]

Actually, we could have feeCount and ledgerCount

[sydneynotthecity]

Actually, we could have feeCount and ledgerCount

I still think feeCount is a little confusing for end users. I would prefer either sorobanTransactionCount or observationCount. So that it's more clear what fees are counted.

[2opremio]

Actually, we could have feeCount and ledgerCount

I still think feeCount is a little confusing for end users. I would prefer either sorobanTransactionCount or observationCount. So that it's more clear what fees are counted.

I will go with transactionCount

[2opremio]

This is ready for review. @tamirms @sydneynotthecity @janewang PTAL