Stop rate-limiting asset-signed-url requests

[jschaul]

After not using the wire client for some time, it can easily happen that many conversations have many assets that should be downloaded. We may wish to be more lenient on asset download (well, getting signed URLs to download assets) requests. See https://wearezeta.atlassian.net/browse/SQCORE-1372 and https://wearezeta.atlassian.net/browse/SQSERVICES-1763

Checklist

• Add a new entry in an appropriate subdirectory of changelog.d
• Read and follow the PR guidelines

[tlebon]

@jschaul i have created a ticket for the FE side of things if you would like to attach https://wearezeta.atlassian.net/browse/SQSERVICES-1763

[akshaymankar]

Have the downsides/risks of this been considered? If so, can you please write them here or link it?

[jschaul]

I updated the description to include links to the two related issues.

Have the downsides/risks of this been considered? If so, can you please write them here or link it?

The only risk I can see here is a bigger amount of requests going to cargohold for getting an asset link, or deleting an asset, and a bigger amount of requests going to AWS for this. As none of these requests involve streaming of actual asset payloads (that's only /assets without a trailing slash), the only potential risk I see is a form of denial-of-service attack on cargohold (though you would need to create really a lot of requests for this - all the while being authenticated as a Wire user, allowing us to see where this comes from). We already have a few other unlimited API endpoints (/access), which have a higher potential of causing issues for users were it to be denial-of-service-attacked.
@akshaymankar do you see any other risks here?

[akshaymankar]

Sounds good, I don't see any other threats, just wanted to make sure we leave some context here in case we need to look into this in future.