Adds a "never" expiration option

[viktorpenelski]

This is a naive way of solving #92 by adding a "never" expire option by setting the data way into the future.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[viktorpenelski]

I have read the CLA Document and I hereby sign the CLA

[mtlynch]

Cool, thanks for taking this on, @viktorpenelski!

I prefer this approach to #124 because I'm worried about a case where we forget to check for nil time in something like the garbage collector and we end up deleting all the "Never" expire files because they look like they expired.

I think the best approach is to define a var in types.go like this:

var NeverExpire = ExpirationTime(time.Date(3000, time.January, 0, 0, 0, 0, 0, time.UTC))

And then use that for the "Never" option. Then we can edit formatExpiration to special-case the Never option like:

if et == types.NeverExpire {
    return "Never"
}

I refactored the expiration option rendering to happen server side (#126) to make this easier.

[viktorpenelski]

Thanks, @mtlynch, the refactor makes it really easy!

I've added the NeverExpire type alongside GC tests to hopefully catch if someone moves NeverExpire to an earlier time.

Out of curiosity, is there a nicer way to tie a constant variable or a method to a custom type? E.g. instead of having var NeverExpire on its own, have it tied down to ExpirationTime, like ExpirationTime.Never? (for example in Kotlin that would be easy to add with an extension property)
(sry if it is a dumb question, I'm not familiar with Golang)

[mtlynch]

LGTM, thanks!

Out of curiosity, is there a nicer way to tie a constant variable or a method to a custom type? E.g. instead of having var NeverExpire on its own, have it tied down to ExpirationTime, like ExpirationTime.Never? (for example in Kotlin that would be easy to add with an extension property)
(sry if it is a dumb question, I'm not familiar with Golang)

Good question! I don't think this is possible. The closest I can think of is to tie it to a package, the way Golang does with months like time.January. So we theoretically could create a dedicated package called expirations and have a var Never so we'd have the readability of expirations.Never, but that's probably too much just for one var.

It is properly type-checked though. If you try to treat types.NeverExpire as a regular time.Time (instead of a types.ExpirationTime), compilation will correctly fail:

cannot use types.NeverExpire (type types.ExpirationTime) as type time.Time in argument to time.Now().After