Fix versification crash and missing versification table clean up

[pmachapman]

Fixes sillsdev/serval#830

---

This change is 

[codecov-commenter]

Codecov Report

❌ Patch coverage is 86.66667% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.20%. Comparing base (9a21ddd) to head (8396072).

Files with missing lines	Patch %	Lines
src/SIL.Machine/Corpora/UsxFileTextCorpus.cs	0.00%	1 Missing ⚠️
src/SIL.Machine/Corpora/UsxTextAlignmentCorpus.cs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #437      +/-   ##
==========================================
- Coverage   73.20%   73.20%   -0.01%     
==========================================
  Files         440      440              
  Lines       36931    36938       +7     
  Branches     5077     5077              
==========================================
+ Hits        27037    27042       +5     
- Misses       8781     8783       +2     
  Partials     1113     1113              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ddaspit]

@ddaspit reviewed 4 files and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on Enkidu93 and pmachapman).

---

src/SIL.Machine/Corpora/ParatextProjectSettingsParserBase.cs line 63 at r1 (raw file):

                else
                {
                    using (Lock.Lock())

Why do we only lock in this case?

[Enkidu93]

Thanks for cleaning this up! Any ideas what particular arrangement was causing our continued problems? I'm just wondering if it's a symptom of another problem - e.g. we're getting multiple copies of a corpus or project settings and we don't have to be? Or does this only happen when USFM is fetched multiple times at the same time for projects with the same custom versification (maybe the same source projects 🤔? or we have test projects with duplicate GUIDs?)?

@Enkidu93 reviewed 4 files and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on pmachapman).

[pmachapman]

Any ideas what particular arrangement was causing our continued problems?

The Versification.Table class maintains a static dictionary of unknown versfications. When we load a custom versification, this dictionary is modified, and so the Dictionary.Add() fails. This PR attempts to solve that by always clearing that dictionary after a versification is loaded, and to make sure that an out lock is used in ParatextProjectSettingsParserBase so that the logic that adds/removes form that dictionary is not executed concurrently.

@pmachapman made 2 comments.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on ddaspit).

---

src/SIL.Machine/Corpora/ParatextProjectSettingsParserBase.cs line 63 at r1 (raw file):

Previously, ddaspit (Damien Daspit) wrote…

Why do we only lock in this case?

As far as I can tell, this is the only place the code is called from Serval, and so may in certain circumstances be run concurrently. To effectively lock the other locations, we would need a global lock (Versification.Table.Implementation.Load() already has a lock within it), and I thought that might be overkill.

If you think we need a global lock, please let me know of a suitable class that you think would work for it (I was unsure of this).