process new signage points no more than once

[arvidn]

there are two places we call signage_point_post_processing() from.

1. when we receive a new signage point from a peer, and we don't already know about it. We add it to our full node store and call the post processing function. We do all of this while holding the timelord_lock. This ensures we don't receive the same SP multiple times and end up adding them multiple times. The checking if we have it, adding it and post processing all happens atomically, by holding the timelord_lock.
2. when receiving a new peak, we iterate over the signage points of the block, and we call the post processing function for them. We do not currently hold the lock or check to see if we have already seen the signage point.

This patch acquires the timelord_lock while iterating over the signage points in a new peak, to ensure the iteration does not interleave with receiving any new signage points. It also checks to see if we already have the signage point, and if so, skips calling the post processing function for it.

This is believed to fix an issue where we sometimes would send the same signage point multiple times to the farmer.

[arvidn]

I will not have time to develop a test to exercise this. we may have to punt or resort to manual testing

[altendky]

just putting a hold on this while i run it for a bit and explore

[github-actions]

This PR has been flagged as stale due to no activity for over 60 days. It will not be automatically closed, but it has been given a stale-pr label and should be manually reviewed by the relevant parties.

[arvidn]

this change might fix #11757

[github-actions]

This PR has been flagged as stale due to no activity for over 60 days. It will not be automatically closed, but it has been given a stale-pr label and should be manually reviewed by the relevant parties.

[github-actions]

File	Coverage	Missing Lines
chia/full_node/full_node.py	87.5%	lines 1653
chia/full_node/full_node_store.py	50.0%	lines 370

Total	Missing	Coverage
10 lines	2 lines	80%

[github-actions]

This PR has been flagged as stale due to no activity for over 60 days. It will not be automatically closed, but it has been given a stale-pr label and should be manually reviewed by the relevant parties.