This fixes a race condition we debugged.

Explanation

Many new and/or low-resource languages must have seen this: You remember that you already recorded a sentence, you record it again, but when you submit it a pop-up comes out saying it could not be saved with two options: Retry - Cancel.
Even if you retry, you cannot pass it, the only way is to press cancel.
We found out the code is correct, but there is a race condition: The database (DB) updates are slower than selects. Here is what was happening:

• The front-end (FE) requests 25 sentences for being recorded. The back-end (BE) provides them.
• The user submits 25 sentences 5 by 5. The first 4 batches go without a problem. After the last 5 (or less remaining) are sent, FE requests a new batch (of 25).
• While the database is updating the sentence tables incrementing the recorded counts (slow), it also selects new set - but with not-yet-updated values. This is a race condition. So the user gets a random selection of sentences, where some of them might be from the last set of the previous batch. If the text-corpus is small, or the contributing user count is slow, or small number of users record much (which is very much the case for every new/low-resource language) this happens more.
• The user records that sentence again and it gets rejected - because by rule (to prevent bias) a user can only record a sentence once.

In this fix, we keep the sentence_id's which got recorded - for each user in memory for an hour and filter out from the results, which effectively overcomes the race condition caused by slow DB UPDATE process.

Related issues to be closed

TBA