Stop refreshing after every POST named operation

[Leonard Richardson]

Currently we refresh the representation of a resource after every PATCH and every named operation that uses POST. This is unnecessary in most cases, because in the common case the only change that the resource has undergone since we got its representation are the changes we made.

In the PATCH case we should be able to just write through the changes into the client-side stored representation, rather than fetching a whole new representation. The POST case is trickier, but we should be able to send a (possibly custom) Cache-Control directive in the response that tells launchpadlib that the POST operation (or someone else's actions in between our GET and our POST) has invalidated our model of the resource. That way launchpadlib can distinguish between POSTs that modify the resource and POSTs that don't.

We can already distinguish POSTs that create a new resource, which always send a 201 response code. AFAIK those are the only POST operations we expose that _don't_ modify the resource POSTed to. So for now we can rely on that. But it's easy to imagine a POST operation that modifies a number of related resources but no the resource POSTed to, and there's no need to refresh in that case.

There are a couple solutions for the PATCH case. One is to make general whatever Cache-Control directive we use or invent. So if you do a PATCH and provide Unless-Modified-Since, the server might let your patch through but warn you that someone else made a non-conflicting modification in the meantime and that your representation is therefore out of date.

Another is to use PUT instead of PATCH. If someone else modified the representation in any way, the PUT will fail. We can refresh and try the PUT again. If there was no modification we won't have to do a refresh because we know our representation is still up to date.

[Leonard Richardson (leonardr)]

This is no longer as important because we don't refresh on PUT and PATCH anymore. The server sends back an up-to-date representation in response and we start using that. So now we just need to distinguish between POST requests that change the resource and POST requests that don't.

[Martin Pitt (pitti)]

This still requires having workarounds which look like

                    try:
                        a.removeFromBug()
                    except HTTPError:
                        pass

so it's still a real issue (originally reported as bug 315387)

[Brian Murray (brian-murray)]

I just ran into this with removing an attachment from a bug report. Luckily, I knew that the apport retracer does this and looked at its code to find this bug report. I don't believe sorting this error is very easy for most people though.