Feat/long-term scheduler

[L-M-Sherlock]

@ImSingee I translated most code from ts-fsrs, so the code style seems weird to Golang. Could you help me improve it? I have added the unit test.

[ImSingee]

@L-M-Sherlock I have refactored the code to make it more in line with Go's philosophy.

Notable Points:

1. Scheduler now becomes a struct (no Scheduler interface and no abstractScheduler now)
2. The Scheduler can only be constructed from Parameters now. (The constructor becomes the method of the Parameters)

And some points related to end-user:

1. Now you should use the new FSRS as an entry point (previously Parameters)

[ImSingee]

Backward un-compatible:

1. DefaultParam().Repeat becomes NewFSRS(DefaultParam()).Repeat now
2. If Parameters is deserialized from the outside, the EnableShortTerm will be false, and then the new LongTermScheduler will be used

@L-M-Sherlock Should we do more to make it compatible with v2 (since its launch is so close)?

[L-M-Sherlock]

Should we do more to make it compatible with v2 (since its launch is so close)

I hope it's more consistent with ts-fsrs interface.

[ImSingee]

@L-M-Sherlock

For the first one, It's likely possible to just add a deprecated Repeat method for Parameters which just calls the NewFSRS(p).Repeat.
For the second one, since I don't know too much about the short-term and long-term algorithm of FSRS-5, I cannot give a suggestion.

Anyway, we can definitely just release a v3 version. 😂

[L-M-Sherlock]

OK, let's release the v3 version. But I also plan to implement the fuzz feature. If we implement it, should we release v4?

[ImSingee]

OK, let's release the v3 version. But I also plan to implement the fuzz feature. If we implement it, should we release v4?

For golang, we should release a new major version if and only if we do something not back-compatible.

So, if the fuzz feature requests the user to change their existing code, we should release v4. And if not, we should keep using v3.

[L-M-Sherlock]

Thanks for the clarification about the versioning of golang module. Fuzz only requires to add a new variable to the Parameters structure. I think it's back-compatible?

[ImSingee]

Thanks for the clarification about the versioning of golang module. Fuzz only requires to add a new variable to the Parameters structure. I think it's back-compatible?

It depends. I think for most cases people will use DefaultParam to init Parameters, and it's so back-compatible.

But there's another case if the user deserializes the Parameters from DB, and in this scenario, the newly introduced variable will become the zero value in golang. So this may be back-incompatible. However, if the newly introduced variable is only used in the fuzz feature, it would still be considered backward-compatible.

So in fact, this is still a case-by-case scenario, and we can discuss it further if the feature is available.

[L-M-Sherlock]

OK. Let's update the go.mod file to upgrade the version, and delay the discussion about v4 to the next PR. I will implement the fuzz feature when I come back from vacation.