Perf issues around tracking ids when populate large invoice (or all invoices for an account)

[sbrossie]

The code inside invoice will populate the shell invoice with its items, payments, tags and tracking ids. However there are many code paths where such of these elements are not useful.

In particular, we should look at whether for internal use (e.g. invoice run), we could bypass tracking ids.

A more elaborate approach would be to make such loading lazy and only call it if such data is being used.

[sbrossie]

Anytime we rehydrate an invoice from disk, we 'populate' all the elements of the invoice, including the trackingids.

I don't believe such trackingIds are used anywhere internally in the code, except for when this needs to be returned to the client; in which case this is first set in the InvoiceModelDao#trackingIds, and then in the DefaultInvoice#trackingIds.

Since we don't have an api flag to bypass returning such trackingIds, the first goal would be to not populate those for any internal KB invoice - i.e we only populate when fetching an Invoice from api.

In a subsequent Kill Bill version (e.g. 0.26.x) we could consider adding a flag to decide whether to return or not such items based on client needs.

To be more concrete, fetching trackingIds could probably be disabled in the following use cases:

• create refund as shown here
• delete CBD as shown here
• compute invoice item adjustment as shown here
• set parent invoice as shown here and here
• cba complexity as shown here

In addition to those, we should check for all the get paths that are used for apis, whether we also use those internally and possibly introduce a flag to discriminate between internal and external (invoice api) use cases.