Refactor where we are calling out to update symlinks

[agjohnson]

There are a number of questions I don't think we have answers for around symlinking, and a number of bugs that are present because of this. Our patterns for when to update our symlinks are a bit inconsistent and so it might help to formalize on this.

Right now:

• Some symlinking happens on model save -- this makes sense as a central point for updating
• Some symlinking happens in tasks -- when builds are complete, they fire off their own symlink update tasks
• Some symlinking happens from form save -- this could probably be moved to model .save()

While it might not be able to accumulate these calls in model .save() methods, there might be other patterns that we can make use of here to simplify the logic.

The design decision here lies around which pattern works best and makes the code more understandable. Before any of us can weigh in on which pattern would work, we'll need to:

• Enumerate where we are calling symlink code now
• Note the purpose for each call to update our symlinks

From there, we can make a decision about if the current location of the calls to update our symlinks make sense, or if we can centralize and standard on a pattern.

Raised in #3649

[ericholscher]

💯 -- we definitely need to simplify this logic, but I agree that there isn't one obvious path forward.

[humitos]

Linking #4550 here since we are planning to remove the symlinks and this issue could be closed if that happens.

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further. Thanks!

[stsewd]

I don't think this should be closed, but looks like a low priority refactor.

[stsewd]

We are definitely going to remove symlinks, so closing :)