Build version req

[dimpar]

Note: the following changes did not affect past rewards distributions because we had only 1 available version of the keep-core client.

This PR is about refactoring and fixing how we determine the build version requirement for the client in a given rewards interval. Here's an example:

                 v1 or v2                    v2
         --/------------------\|---------------------------|
Timeline -*--------|-----------*---------------------------|->
        May25    June1       June8                      June30
          v2               (v2+delay)
Where:
Rewards interval: June 1 - June 30
v2 is released on May 25
delay = 14 days
v2 + delay = May 25 + 14 days = June 8
Between June 1 - June 8 a client is allowed to run v1 or v2
Between June 8 - June 30 a client is allowed to run only v2

It can happen that between June 8th and June 30th a node operator might still run an older version v1 but switches to the latest version just before the end of the rewards interval, ie. June 30th. This PR captures all the instances and marks an operator as it didn't fulfill the version requirement, since starting June 8th every single instance must run on the latest version.

This PR also changes the way how we display versions in the JSON output file for a given instance, e.g.

"instances": {
    "24.129.87.224:9601": {
         (...)
         "version": {
             "v2.0.0-m1": 1675956180, // last registered timestamp of this version in a given interval
             "v2.0.0-m2": 1676073840  // last registered timestamp of this version in a given interval
          }
     }
},

[manumonti]

I don't see how the v2.0.0-m2 special case is managed in the code.

I mean, we don't want to apply the 2 weeks upgrade delay for this version. Instead of this, we want to accept all nodes with v2.0.0-m1 until February 27th, right?

How does the code manage this special case? Sorry if dumb question.

[dimpar]

I don't see how the v2.0.0-m2 special case is managed in the code.

I mean, we don't want to apply the 2 weeks upgrade delay for this version. Instead of this, we want to accept all nodes with v2.0.0-m1 until February 27th, right?

How does the code manage this special case? Sorry if dumb question.

For February we will enter this if statement, ie. the latest tag was created before the interval (Jan 25th) and cutoff date for the upgrade is somewhere within the interval. We will validate two versions: the latest and the one before the latest.

When calculating February rewards, we'll need to change https://github.com/threshold-network/merkle-distribution/blob/build-version-req/src/tbtcv2-rewards/rewards-constants.ts#L1 to 2886195 which will be added to the latest version timestamp that marks the cutoff date to Feb 28th 00:00:00 GMT. I assumed we can do it by hand, but if we need a PR then certainly I can create one. But for March rewards, we will need to revert that back to 2 weeks.

[manumonti]

When calculating February rewards, we'll need to change https://github.com/threshold-network/merkle-distribution/blob/build-version-req/src/tbtcv2-rewards/rewards-constants.ts#L1 to 2886195 which will be added to the latest version timestamp that marks the cutoff date to Feb 28th 00:00:00 GMT. I assumed we can do it by hand, but if we need a PR then certainly I can create one. But for March rewards, we will need to revert that back to 2 weeks.

Ah, got it. It makes sense. I think it's better to change this const variable in the same PR that the new distribution allocation.