fix calculation of expected tables and create tables from upcoming schema considering grace period

[sandeepsukhani]

What this PR does:
This PR includes following to fixes:

1. Fix calculation of expected tables:
   While calculating periodic tables for a given duration, the end time of the duration was used to find what the last table number would be. To avoid creating an extra table, there was a check whether end duration was ending exactly at end of the day which was causing the whole table to be omitted. Instead of checking against a days duration, this PR uses periodic table duration to check whether we have an extra table.

2. Create tables from upcoming schema considering grace period:
   We skip creating tables for configs whose start time is after now() which means tables would not be created until we already are past the start time of config. This can cause writes to fail since tables won't be created already for writing data to it.
   This PR checks whether the config start time is before now() + gracePeriod when creating tables.

Which issue(s) this PR fixes:
Fixes: #1920
In #1920, the start time of config was not set to the day when tables would rotate. When the time was just short by grace period before hitting next config, this block started calculating tables for duration from start-of-active-schema to start-of-next-schema. Since the end was not a multiple of table duration but was a multiple of a days duration, issue 1 above was causing table manager to unexpectedly drop the active table.

Checklist

• Tests updated
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[pracucci]

LGTM

[pracucci]

Note to myself: this looks a safe change to me. We're going to create the new table a bit ahead of time, which is what we want.

[bboreham]

Seems legit. One thought about a comment.

[bboreham]

I think this comment is now less explanatory. Could say something like “If interval ends exactly on a period boundary, don’t include the upcoming period”.