feature(rule): add rule time-after-leak

[chavacava]

This PR adds a new rule: time-after-leak
The rule spots the known problem of temporary leak of goroutines underlying time.After()

As described by the documentation of time.After(), version 1.23 of Go fixed the problem thus the rule skips files of packages with a Go version equal or higher than 1.23.

The PR also introduces lint.IsAtLeastGoVersion to factor-out the common code of lint.IsAtLeastGo1*

[denisvmedia]

Hi @chavacava thank you for the PR. I'm wondering if we really should introduce this rule, since go versions below 1.23 are already out of their life cycle. I do however like the idea of the improvements in the code you made.

[denisvmedia]

LGTM (with a question about linting go projects with go version below 1.23)

[ccoVeille]

I share @denisvmedia point of view, with one remark anyway:

I have read something yesterday about the fact the bug was only partially fixed for Go 1.23+

Meaning it's way better now, but it still leaks somehow in some circumstances.

I will have to find back where it was.

[ccoVeille]

Found it back.

https://dev.to/iw4p/how-timeafter-can-cause-memory-leaks-in-go-and-how-to-fix-them-1kg3

Now,I'm doubting about the fact we can trust this article.

I mean I checked almost viable resources and found nothing about it.

[ccoVeille]

In this error message, you could mention one solution is also to upgrade to Go 1.23+

Or the opposite that this error exists only for version prior 1.23

The same way use-any mentions any can be used with Go 1.18+

https://github.com/mgechev/revive/blob/master/rule%2Fuse_any.go#L50

[ccoVeille]

Here I would like to suggest using a message like the one used for omitzero in structtag rule

revive/rule/struct_tag.go

Line 330 in 57ed899

return `prior Go 1.24, option "omitzero" is unsupported`, false

prior Go 1.24, option "omitzero" is unsupported

[ccoVeille]

I would mention here it's for older Go versions, or something like

Suggested change

	| [`time-after-leak`](./RULES_DESCRIPTIONS.md#time-after-leak) | n/a | Suggests replacing `time.After` with `time.NewTimer` to prevent goroutine leak | no | no |
	| [`time-after-leak`](./RULES_DESCRIPTIONS.md#time-after-leak) | n/a | Suggests replacing `time.After` with `time.NewTimer` to prevent goroutine leak, if needed | no | no |

Suggested change

	| [`time-after-leak`](./RULES_DESCRIPTIONS.md#time-after-leak) | n/a | Suggests replacing `time.After` with `time.NewTimer` to prevent goroutine leak | no | no |
	| [`time-after-leak`](./RULES_DESCRIPTIONS.md#time-after-leak) | n/a | Suggests replacing `time.After` with `time.NewTimer` to prevent goroutine leak for old Go versions | no | no |

[ccoVeille]

But maybe, one interesting thing could be to add a column to this table to mention the Go version specification

Something like < 1.23 here, and > 1.18 for use-any, and others.

[ccoVeille]

The following issue was opened

• Add go version information for each rule in documentation #1311

[alexandear]

Please add a new line before:

Suggested change

	## time-after-leak
	## time-after-leak

[alexandear]

I propose adding a note similar to the ones in range-val-address and range-val-in-closure:

Suggested change

	_Configuration_: N/A
	_Configuration_: N/A
	_Note_: This rule is irrelevant for Go 1.23+.

[chavacava]

Closing. Niche rule for old Go version