Fix #1094

[CBroz1]

Description

#1050 migrated from a for-loop-insert pattern to a for-loop-append pattern, but did not check whether or not the appended list was edited in subsequent iterations.

# insert pattern
for item in my_list: 
    item.update(other_data)
    tbl.insert1(item)

# append pattern
inserts = []
for item in my_list:
    item.update(other_data)
    inserts.append(my_func(item))
tbl.insert(inserts)

The former inserts the data as-is, preventing subsequent loop iterations from changing in-memory values. The latter reduces database calls to speed up the process and prevent inserts in the event a later iteration fails, but is susceptible to later iterations doing in memory manipulations of the previous insert. Making sure to append item.copy() fixes this issue.

While this bug is present in a release, using the bugged version will result in the error shown in #1094 - integrity error because the part table will refer to a non-existent master. sg_keys is susceptible to this effect, but not sge_keys as the sge_key is decomposed with ** when appended to the inserts list.

Checklist:

• No. This PR should be accompanied by a release: (yes/no/unsure)
• N/a. If release, I have updated the CITATION.cff
• No. This PR makes edits to table definitions: (yes/no)
• N/a. If table edits, I have included an alter snippet for release notes.
• N/a. If this PR makes changes to position, I ran the relevant tests locally.
• I have updated the CHANGELOG.md with PR number and description.
• N/a. I have added/edited docs/notebooks to reflect the changes