[fix] #3262: Don't prematurely execute time-triggers before their start timestamp

[Arjentix]

Description

While original issues doesn't state it clearly I think that the problem was premature execution of time triggers.
So that trigger could be executed even before start. I fixed this.

• Now it's forbidden to register schedule-based time-trigger with start point before latest_block_timestamp + consensus_estimation time, where consensus_estimation = 4 secs and is a hardcoded constant. Everithing before this timestamp is considered already analyzed by Iroha. In other words -- time-triggers in the past are forbidden.
• As a consequence it's forbidden to register such trigger in genesis
• Now premature time-trigger look up is forced to not to execute trigger start point is in future
• This behavior is tested by a fixed change_asset_metadata_after_1_sec test

Forbidding time-triggers in the past was the simpliest solution and I actually think it was making sence to implement that in the initial solution.

Linked issue

• Closes [suggestion] Time trigger first execution time #3262

Benefits

• Less confusion about time-trigger execution time
• No more painful triggers in the past

Checklist

• I've read CONTRIBUTING.md
• I've used the standard signed-off commit format (or will squash just before merging)
• All applicable CI checks pass (or I promised to make them pass later)
• (optional) I've written unit tests for the code changes
• I replied to all comments after code review, marking all implemented changes with thumbs up

[coveralls]

Pull Request Test Coverage Report for Build 8070574387

Details

• -16 of 20 (20.0%) changed or added relevant lines in 3 files are covered.
• 3125 unchanged lines in 56 files lost coverage.
• Overall coverage decreased (-0.3%) to 56.519%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
core/src/smartcontracts/isi/triggers/mod.rs	0	2	0.0%
data_model/src/isi.rs	0	2	0.0%
data_model/src/events/time.rs	4	16	25.0%

Files with Coverage Reduction	New Missed Lines	%
core/src/sumeragi/network_topology.rs	1	98.78%
data_model/src/events/time.rs	1	67.81%
tools/kagami/src/crypto.rs	1	12.12%
data_model/src/metadata.rs	2	78.87%
primitives/src/unique_vec.rs	2	91.24%
config/src/kura.rs	3	80.0%
config/src/logger.rs	5	72.73%
logger/src/lib.rs	5	94.12%
tools/kagami/src/main.rs	5	0.0%
crypto/src/signature/secp256k1.rs	7	96.09%

Totals
Change from base Build 7884695009:	-0.3%
Covered Lines:	22455
Relevant Lines:	39730

---

💛 - Coveralls

[s8sato]

Can we say we confirmed the following points:

1. the trigger was successfully registered
2. interval (time-event) and schedule (time-event acceptor points) matched
3. but the trigger did not execute because it was premature
4. now that it is past the schedule.start time and other conditions met, the trigger has successfully executed

I think at least one more query will be required

[s8sato]

I cannot read the role of PERIOD here from its name

[Erigara]

Going to remove it

[s8sato]

Does this change guarantee anything new?
In each case before and after, the intersection of schedule and interval seems to be empty, regardless of where schedule.start is

[Erigara]

I think this tests isn't testing anything new.
In each case two interval is located between two schedule points.
I'm going to revert it.

[VAmuzing]

What if we introduce something like scopes to show why it's equal to 2? And have a variable that we increment?
I see that it's a test but that value might cause confusions even with the commentary