Assign ~thread.thid with thread_id value

[usingtechnology]

The previous assignment used a value from a field that had not been assigned yet. So, use the correct thread_id value for the thid.

Fixes #2259

The fix originally discussed in #2259 is too aggressive and after reviewing the code it is clear that there can be empty ~thread and they are expected to be dealt with by the receiver. In this case, we were attempting to set the thid but just using an unassigned value.

[dbluhm]

The new dev dependency is interesting. I usually just use the random package directly, telling it to select values from ascii (or something like that). But I'm happy with this change.

[usingtechnology]

I can remove the dev dependency, I really only added it to kick off the tests again (failed in GH) as I do not have access to manually restart the checks.

[swcurran]

I’d say remove the dependency. We don’t want them lightly added. And until you are a maintainer, please just get me to re-kickoff the tests. I can do that.

[andrewwhitehead]

Should we be updating cred_ex_record.thread_id if it's unset?

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[usingtechnology]

Should we be updating cred_ex_record.thread_id if it's unset?

It was always being set AFTER being used to set thid.