Make `getTLDs` request more lightweight by adding a new parameter called `includeNumberOfAliases`

[map1336]

Is your feature request related to a problem? Please describe.

Currently, the getTLDs request shows all available TLDs registered onchain

The issue is that that each TLD includes the number of aliases registered with it by default

{
  "tlds": [
    {
      "account": "0",
      "accountRS": "S-2222-2222-2222-22222",
      "aliasName": "signum",
      "timestamp": 0,
      "alias": "0",
      "numberOfAliases": 62004
    },
  /// Remaining TLDs...
  ],
  "requestProcessingTime": 2639
}

This is a pretty heavy operation that should be optimized by optionally showing the numberOfAliases
See that requestProcessingTime shows the queries lasted almost 3 seconds, there has been cases where it lasted up to 5 seconds

Describe the solution you'd like
I think there should be a new parameter for actually not showing the number aliases

Something like this:

As an example, if the user set that new parameter to false, number of aliases will not be shown

    {
      "account": "0",
      "accountRS": "S-2222-2222-2222-22222",
      "aliasName": "signum",
      "timestamp": 0,
      "alias": "0"
    }

Additional context
By default this parameter should be true in order to prevent breaking changes on multiple DApps that may use this feature.

Currently i inspected the code on SignumSwap and this is the result:
SignumSwap makes that request, but does not use the numberOfAliases property

Second Additional context
Most wallets may not use that property at all. Example: Signum Mobile Wallet will not use the numberOfAliases property

[damccull]

I think the data format itself is probably fine. Instead of changing the API significantly, this problem can be solved with some database work, I think.

Both postgres and sqlite support the concept of precomputed views, albeit it different ways. We could adjust the schema to create a pre-computed view of these TLDs and related data, triggers to keep them automatically refreshed, and then point the endpoint at that new precomputed table.

Data may be stale for a few seconds after each insert while the view is being refreshed in the database, but that's acceptable with this low-write-count job. The focus is on reading and a pre-computed table will read almost instantly.