Aggregate Universe Stats: always store result of querySyncStats

[GeorgeTsagk]

Our universe stats could run into a case where if in an un-cached state (like on system start-up) the db query takes longer than the default client timeout (usually 30s) then we'd fail the query and return early. This would cause the next client to also receive an error instead of the cached result, making this codepath stuck in an endless failing query. With this change we parallelize the db query and we always wait for the result in order to store it in cache. We may fail the function earlier, but the result will always be retrieved & persisted. This way, even if the 1st client retrieves an error, the next one will receive the cached (late) result of the previous run.

Closes #1304

[coveralls]

Pull Request Test Coverage Report for Build 12815550785

Details

• 29 of 37 (78.38%) changed or added relevant lines in 1 file are covered.
• 10 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.05%) to 40.796%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
tapdb/universe_stats.go	29	37	78.38%

Files with Coverage Reduction	New Missed Lines	%
internal/test/helpers.go	2	86.95%
tapgarden/caretaker.go	4	68.87%
commitment/tap.go	4	83.86%

Totals
Change from base Build 12810137371:	0.05%
Covered Lines:	26588
Relevant Lines:	65173

---

💛 - Coveralls