feat(stdlibs): simplify time pkg & remove tz + monoclock logic related

[MikaelVallenet]

fix #851

The purpose of this Pull Request is to simplify the Time pkg, which comes from Go, in order to remove unnecessary functions for Gno.

This Pull Request removes the concept of monotonic clock, which corresponds to the time since the start of the program, often used to calculate the time interval between two events more reliably.

I've also removed the notion of timezone, and now an instance of Time is composed as follows:

type Time struct {
	sec  int64
	nsec int32
}

When I parse a date with a different timezone, it's automatically transformed into UTC.
However, the goal would be to allow a Time instance to be displayed in a specific timezone with a markdown pattern, especially for Gnoweb.

[2024-10-11 12:33:41](#local)
[2024-10-11 12:33:41](#Europe/Rome) => 2024-10-11 14:33:41 (Summer time)

Most of the PR is code deletion, not addition, especially the bitwise logic. see article

I've also adapted some unnecessary methods to avoid breaking realms, such as the Zone method, which returns the tz name and offset before the realm name, and is used in the events realm.

// This method is here to avoid breaking changes but always return UTC and offset 0
func (t Time) Zone() (name string, offset int) {
	name, offset = "UTC", 0
	return
}

I also kept some unused param like Location in Date to validate the CI & keep same API as Go:

func Date(year int, month Month, day, hour, min, sec, nsec int, loc *Location) Time {...}

In the code snippet above, i kept the loc parameter even if i don't use it anymore.

I'd like to take this opportunity to say that I haven't answered the testing question, because the PR seems tedious enough to review as it is. If this PR ends up being merged, I'm thinking of doing a second PR for the testing part, to keep things as atomic as possible.

For what concerns testing, I think it's reasonable at the start of gno test to set a TimestampSeconds at the UNIX timestamp of starting the test. Or maybe we want it fixed in time... but, seeing as this is the testing environment, if we end up wanting to change it we can just change it later.
You may want to move internal/os.Sleep to the testing stdlib's time. Or maybe, let's have a SetNow which can take a time.Time to be set as the current value of Now().
Originally posted by @thehowl in #851 (comment)

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.38%. Comparing base (287c22e) to head (411f022).
Report is 7 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3016      +/-   ##
==========================================
- Coverage   63.39%   63.38%   -0.02%     
==========================================
  Files         565      565              
  Lines       79457    79457              
==========================================
- Hits        50369    50361       -8     
- Misses      25695    25700       +5     
- Partials     3393     3396       +3     

Flag	Coverage Δ
contribs/gnodev	60.57% <ø> (ø)
contribs/gnofaucet	14.82% <ø> (ø)
gno.land	67.37% <ø> (ø)
gnovm	67.82% <ø> (-0.06%)	⬇️
misc/genstd	79.72% <ø> (ø)
tm2	62.47% <ø> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[moul]

It looks good globally. However, after discussing with Jae which parameters should be specified in the new x/params module (#3003), we believe it would be beneficial to include a "global chain default timezone" to accommodate more regional chains. We can apply the same logic of markdown-based conversion. Instead of having no timezone support or encouraging per-contract timezone support, we ideally want to implement per-chain timezone support.

[MikaelVallenet]

I understand and agree with you, i will look to adapt the PR to set the default tz as a parameter of the chain handle by x/params