Update to upstream version '1.4.4'
with Debian dir bfe4348a86fbf037ddeaaad6842ec467143411d1

This ensures the deposit checks in the elastic infra (using azure objstorage) is
working. There is currently no way to prevent the content-encoding from being detected
and stored in the blobstorage (various tryouts have been tested to no avail). That
content-encoding, is then preventing the checking/reading to work (failing [2]).

Following the documentation, a workaround has been implemented to reset a posteriori the
content-encoding [1].

It's not proper but, from repl experimentation, it's working which is better than the
actual failure.

[1] https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-properties-metadata-python

[2]
```
HttpResponseError: ('Received response with content-encoding: gzip, but failed to decode it.', error('Error -3 while decompressing data: incorrect header check'))
```

Refs. swh/infra/sysadm-environment#5129

Update to upstream version '1.4.3'
with Debian dir 5d705e553436af21a342fad000978b1f4f45899f

Use None instead of empty string to try to prevent content-encoding to be set when
writing.

Refs. swh/infra/sysadm-environment#5129

Update to upstream version '1.4.2'
with Debian dir 2b4aef9f7ac345385fda3320ce6b248a5c9e3950

Currently, the writing in the azure objstorage adds extra headers to the blobs. Which
prevents the correct reading of those blobs when checking the tarballs.

According to the documentation, this option opening should allow to configure more
appropriately.

Refs. swh/infra/sysadm-environment#5129

Update to upstream version '1.4.1'
with Debian dir ae89963d8b634ae2841b7c42ddbca165075036a3

If done on the full path, the conditional technically fails the check for the wrong
reason. This also adds tests on this case.

Refs. swh/infra/sysadm-environment#5129

Update to upstream version '1.4.0'
with Debian dir e0639530ad4e76de52dee4a5738eef298948d9d9

Refs. swh/infra/sysadm-environment#5129

Similar adaptation of the deposit_check endpoint to allow reading remote tarballs when
using remote storage backends.

Refs. swh/infra/sysadm-environment#5129

Using the File api is consistent across various storage backends. The previous
implementation was only working for file storage. As we are migrating towards remote
backends, this no longer is enough.

Unfortunately though, we cannot rely on zipfile.is_zipfile or tarfile.is_tarfile as
those only works with local filepath. So we need to rely on testing & failing with
exception trapping to read properly the tarballs...

Refs. swh/infra/sysadm-environment#5129

They were only checking one tarball case (the ones reference in the ready_deposit_ok
deposit). This now creates as much deposit as there are extensions to check.

This only had to adapt the deposit so it's provided with a valid metadata. Otherwise,
the metadata checks were invalid, failing the overall tests.

Refs. swh/infra/sysadm-environment#5129

Refs. swh/infra/sysadm-environment#5129

Moreover, it was making some deposit tests failed when building packages
due to a side effect on the swh_storage fixture.

As for the webapp, ensure django 2.2 from backports is used on buster
as everything is already setup in puppet to have it in production.

Refs. swh/infra/sysadm-environment#5137

Update to upstream version '1.3.4'
with Debian dir ca8fc375b99aac4a02fdb23e64313710a919f0b4

This reverts commit bb22867c.

Not ready yet

So the tests can work out of the box.

Refs. swh/infra/sysadm-environment#5137

Update to upstream version '1.3.3'
with Debian dir 21401a46d54a7627001d7181b2fe69cb4c2b58ad