feat: support usage based pricing

[turip]

Overview

Add line-splitting capability to support mid-period invoicing. See README.md for more detailed information.

Algorithm

To achieve the behavior described above, we are using line splitting. By default we would have one line per billing period that would eventually be part of an invoice:

                period.start                                              period.end
Line1 [status=valid] |--------------------------------------------------------|

When the usage-based line can be billed mid-period, we split the line into two:

                     period.start              asOf                              period.end
Line1 [status=split]         |--------------------------------------------------------|
SplitLine1 [status=valid]    |------------------|
SplitLine2 [status=valid]                       |-------------------------------------|

As visible:

• Line1's status changes from valid to split: it will be ignored in any calculation, it becomes a grouping line between invoices
• SplitLine1 is created with a period between period.start and asof (time of invoicing): it will be addedd to the freshly created invoice
• SplitLine2 is created with a period between asof and period.end: it will be pushed to the gathering invoice

When creating a new invoice between asof and period.end the same logic continues, but without marking SplitLine2 split, instead the new line is added to the original line's parent line:

                     period.start              asOf1          asof2                period.end
Line1 [status=split]         |--------------------------------------------------------|
SplitLine1 [status=valid]    |------------------|
SplitLine2 [status=valid]                       |---------------|
SplitLine3 [status=valid]                                       |---------------------|

This flattening approach allows us to not to have to recusively traverse lines in the database.

[turip]

This will be removed as soon as we have better granularity.

[hekike]

just double checking: is this is also splitAt and and previous ends at splitAt one should be exclusive when we query usage

[turip]

The code assumes that (added the comment):

// Period represents a time period, in billing the time period is always interpreted as
// [start, end) (i.e. start is inclusive, end is exclusive).

This is aligned with the current logic where clickhouse's tumbleStart is inclusive and tumbleEnd is exclusive.

[hekike]

I'm not sure Max works here. Max of period chunk is different then max of whole period

[turip]

Yes, sorry, I was in a bit of rush for the meters, I have updated the docs and the algorithm.

[hekike]

feature has group by filters that should be applied here too

[turip]

It's already included here: https://github.com/openmeterio/openmeter/pull/1787/files#diff-12d9d74ba62a6275562925d58ede10dfb9708c723129ef2b114e2053efc63473R79-R84