[server] Don't set EXHAUSTIVE when there is a time filter

Summary:
This solves ENG-854: History Lost in Bird App Channel. The issue was that fetchMessageInfos was set up to assume that if we queried for 20 messages, but got fewer than that back from MySQL (0-19), then we could conclude that we've reached the start of the thread (messageTruncationStatuses.EXHAUSTIVE).

This is no longer true if we have an active time filter. The time filter can cause us to return fewer than requested messages simply because there weren't enough newer than the time filter.

We should stick with UNCHANGED in these cases, which in freshMessageStore will result in startReached: false, and in mergeNewMessages will not change startReached.

Test Plan:

1. I tested different values of defaultMaxMessageAge such that some threads would return fewer than defaultNumberPerThread, and some threads would return 0
2. I tested threads that needed a fetchMostRecentMessages, and threads that needed multiple fetchMessagesBeforeCursor to get to the start
3. I made sure all threads loaded all the way to the start of a thread if I kept scrolling

Reviewers: palys-swm, atul

Reviewed By: palys-swm

Subscribers: Adrian, karol-bisztyga, benschac

Differential Revision: https://phabricator.ashoat.com/D3410