Project updated when subproject modified

[humitos]

Closes #3396

To Do:

• find the correct before/after filesystem
• write the test in a proper way
• make the test fail/pass manually
• implement the solution proposed in the original issue

[humitos]

I have some questions/doubts that are related to this PR (maybe to be implemented in another -but related):

• when a Version is deleted, we are triggering clear_artifacts and symlink_project but the later is triggered before object deletion; so, I think if the task is ran before it's effectively deleted the symlink won't be properly synced:

https://github.com/rtfd/readthedocs.org/blob/5472906a067adc60f42556108993255393408410/readthedocs/builds/models.py#L181-L187

• when a (sub)Project is deleted we don't sync anything. I think that maybe we should sync the superprojects

• when a (super)Project is deleted, what should happen with the subprojects?

@agjohnson the PR for the original issue is ready to review --let me know if you want me to squash the commits into one. Although, I would like you to take a look a those questions that I'm raising here.

[ericholscher]

There are a lot of bugs in our "keep symlinks up to date" code. We should write a design document that specifies the exact place that we should be doing sync'ing for this, and then do an audit (and tests!) to make sure that we're actually doing it.

I've tried to build a proper abstraction for maintaining the symlinks in code (https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/core/symlink.py), but that never got pushed back into a proper abstraction for updating/removing/editing symlinks with the lifecycle of the model. I think that is what this PR (and your questions) are addressing.

"What is the correct way to handle updating & syncing symlinks when models change?" is the question we need to answer.

[agjohnson]

The test that you added is a good litmus test for this particular change, but we should add a test that ensures the we're calling the broadcast functions correctly in save().

For instance:

• Symlink broadcast is called as expected
• Symlink broadcast is called for superprojects in the case that we have superprojects and don't have superprojects

[agjohnson]

looks unused, but is it helpful to keep around?

[humitos]

I used a lot while debugging to diff two dicts (current filesystem and expected one). It's a debugging tool that I usually use, but we can definetly remove from here if you want.

[agjohnson]

great, let's keep it for debug purposes

[agjohnson]

A design document might be good to have in the future, but i think will slow down this work without much gain to be had. I'll create a new issue for this under our refactoring milestone.

[humitos]

@agjohnson I just pushed a change with a test to check that broadcast function was called as it's expected. Let me know if that is what you were thinking.

[agjohnson]

Looks great!