Improve startup by eliminating unnecessary migration ranges

[Shaptic]

What

Speed up startup time in "already migrated" cases by eliminating unnecessary ledger range traversals.

Specifically, this includes the following changes:

• Fee stats windows cannot exceed the history retention window, as this doesn't make sense.
• Migrations that are already applied are not added to the list of "multi-migrations".
• Fee stats window building conforms to the migration interface to simplify code.
• LedgerSeqRange has been refactored to always use a value reference.

As a result, if all migrations have occurred, the traversal only occurs over the fee window.

This reduces startup times in a fully-loaded (24hr) database that needs no migrations from ~1m40s to ~1s.

Why

Previously, startup would take a significant amount of time doing nothing because it would loop over a large ledger range and check whether or not a migration was necessary for that ledger. If migrations were already done, it would move on to the next ledger.

In this version, we instead appropriately calculate the ledger range to traverse by only expanding the ledger range if a migration has not already completed.

Known limitations

n/a, tested at length locally

[aditya1702]

Just one nit comment. Otherwise looks good.

[tamirms]

@Shaptic the optimization is great! In summary, I have 3 pieces of feedback:

1. LedgerSeqRange should be an immutable type
2. There is no need for db.BuildMigrations() to return a LedgerSeqRange because it already has a ApplicableRange() function which can be used to obtain the applicable ledger range
3. We can implement a Migration instance for the fee stats and then append it to the MultiMigration returned by db.BuildMigrations() which would allow us to remove the special case handling for fee stats in daemon.go

[tamirms]

looks great!