Deduplicate installs on join form submission when the apt matches

[Andrew-Dickinson]

I don't remember why we stopped doing this deduplication and if it was intentional.

If there was a good reason we stopped doing it, let's keep just the tests from this PR as a way to validate our expectations about this

Closes #549

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.88%. Comparing base (e1d52ca) to head (d591248).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #744   +/-   ##
=======================================
  Coverage   94.87%   94.88%           
=======================================
  Files          89       89           
  Lines        3805     3809    +4     
=======================================
+ Hits         3610     3614    +4     
  Misses        195      195           

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

[WillNilges]

I'm pretty sure this was simply an oversight. It seems reasonable to me to not create a new install if the same person in the same building in the same unit fills out the join form again.

Can you explain what is meant by member_filled_out_the_join_form_long_ago_and_we_recycled_their_install_number? What does "recycling" an install number mean? Did you mean "node number"?

[Andrew-Dickinson]

In this context, recycling just means the "spreadsheet row number" (which we imported as an install number due to the inactive status of that row at import time) was assigned as a network number to another install

In the sense that "node number" ~= "spreadsheet row number" I think that's correct, but it really is an install number in MeshDB parlance