From the source:
> The providing_args argument is deprecated. As it is purely
> documentational, it has no replacement. If you rely on this
> argument as documentation, you can move the text to a code
> comment or docstring.
This is needed so that immediately re-played requests don't fail.
Consider for example the following scenario: a client makes a batch
request that registers correctly on the server, but fails to return
(e.g. a networking error after the request has been processed). The
client would think that the request failed, but the server will already
have the up to date information. This commit just returns a successful
status if this request is sent again (by the client retrying the
request) instead of returning a conflict.
This however doesn't handle the case of a request failing, a
modification being made by another client, and then the request being
retried. This case will stay fail.
This enables us to have db-constraints for making sure that UIDs are
unique, as well as being more efficient for lookups (which are very
common).
The UID should always be the same as the main_item.uid, though that's
easily enforced as neither of them is allowed to change.
We were failing until now, but since the uid is sure to be unique,
we can just assume that if it's the same uid it's the same content.
This means we can just gracefully fail as the data is the same.
Until now, we were raising an error, but we now just do nothing
and consider it a success.
This is especially useful when a network error caused an item to
be uploaded but not updated on the client side.
Verifying the port was causing issues, and anyhow, this check is
paranoid and isn't strictly necessary for security.
The problem is that Django's `get_host()` and the equivalent on some
platforms returns it without the port, though on others (like e.g. the
library we use from JS) it returns with the port. This was inconsistent
and was causing authentication to fail.
We thus relaxed the test to not include the port when matching, which
should make it work consistently across all platforms.
Even with the previous check, there could still be a race condition where two
collections with the same UID are created. Adding this extra check after
will prevent that from happening.
Before this change we were returning all of the removed memberships that happened
after stoken. Though instead, we should just return the removed memberships that
happened after stoken and before the new stoken we are returning.
