Make it clear that EXPIRATION_EPOCH is the last "available" epoch for all entities

[carpawell]

Check all the descriptions/comments. Related to regular and irregular objects, tokens.

[cthulhu-rider]

I suggest to either

1. exclude session and bearer tokens since it's a nonsense to use well-known naming with a change of meaning
2. stop reflecting JWT notations in NeoFS tokens

[carpawell]

If i have to choose, i would do 2.. But also, as @realloc says JWT is about seconds while epoch is about minutes and even hours. JWT allows inevitable time delta which means "somewhen near that second expiration should happen" so it is not that strict in the real world.

/cc @fyrchik.

[realloc]

As @carpawell has already mentioned, we live in another time model and technically do the same thing as JWT does with X seconds splay on token expiration checks.

[cthulhu-rider]

IMO in most cases user wants to set expiration epoch - the timestamp when its product becomes unavailable. If he actually wants to set last available claim, he just sets next epoch as an exp claim. I don't see any reason to go off specification (if you fix the desire to follow it).

[realloc]

Let's stick to how we treat expiration epoch for objects.