Use timestamp to communicate collection_timestamp of the parent

[glasserc]

Don't re-use old self.timestamp when notifying of event. Instead,
re-compute it fresh.

Fixes #1769.

• Add documentation.
• Add tests.
• Add a changelog entry.
• (n/a) Add your name in the contributors file.
• (n/a) If you changed the HTTP API, update the API_VERSION constant and add an API changelog entry in the docs
• (n/a) If you added a new configuration setting, update the kinto.tpl file with it.

[glasserc]

Another approach would be to turn the @reify'd timestamp property into a @property. As far as I can tell, the @reify is a performance optimization -- fewer database round trips. Taking it out doesn't seem to break any tests (except for a few that rely on the ability to set the timestamp of a resource).

Running the test suite with @reify on my laptop finishes in 225-235 seconds. Running with @property finishes in 240-255. So I guess we should probably keep the @reify.

@leplatrem suggested that I add a comment to this change explaining it, which I'll do.

[glasserc]

I just added one test (for put) in a section where tests are also present for other verbs. What do you think about this, @leplatrem ? Is this test even in the right place?

[leplatrem]

That looks correct to me ;)

[leplatrem]

Running the test suite with @reify on my laptop finishes in 225-235 seconds. Running with @Property finishes in 240-255. So I guess we should probably keep the @reify.

I'm not sure it's a clear indicator, since most of the test use the memory backend. Some load test maybe more accurate, but again with PG on the same machine I don't know if the difference will be huge.

[leplatrem]

Hello https://github.com/property and https://github.com/reify ✋

[glasserc]

OK. I am going to merge just this smaller fix, knowing that perhaps it isn't the best long-term solution, but right now I don't want to untangle the significance of the timestamp property being reifyd. Thanks!