All times in the list tokens are sourced from the database,
and any comparisons to times in the application can
cause false positive validation errors. We've observed
this from multiple users of the pagination logic, and
the value of this validation is very little compared
to the cost of a single false positive error like this
happening to a real world customer. Therefore, remove
any list token validation using the application time,
except the one monitoring for token expiry, which
should not suffer from the issue to a degree
that matters to our users.
Also refactor validation such that the list token subtype
constructors only perform sanity checks on the values
while punting business logic validation to the validate
method on the new token. This means we avoid
duplicating logic.