Update to upstream version '2.9.0'
with Debian dir 678de30f3ce51fa5b29bcb9eb4b319cf3194cc1d

This class is a mixin that only works with classes that define
this attribute, so it makes sense to declare it.

It also allows generic functions (that take a HashableObject
parameter) to access it without 'type: ignore'.

Update to upstream version '2.8.0'
with Debian dir 2a0eb3550f469cd69a7d41680ae675ccd875ad66

Update to upstream version '2.7.0'
with Debian dir 6b15a8156e4b0b1122df1ae88f663dd3f0956acb

This allows distinguishing multiple potential versions of the mapping
between external objects and their counterparts archived in Software
Heritage, for instance when a loader has a backwards-incompatible change
that should result in objects being loaded again.

The field defaults to zero, in which case it's backwards-compatible with
the previous implementation in terms of identifier computation.

Update to upstream version '2.6.4'
with Debian dir 92f45f224d492f3f0b914e640c27ce17d2a9dcb7

We agreed a while ago they should be IRIs and not just URIs.

This will trigger crashes in swh.storage.cassandra, as
currently expects (wrongly) that origin urls are ASCII.

* empty fetcher name or version is not accepted by cassandra
  (and is nonsensical anyway)
* ditto for non-ASCII (and any non-printable is nonsensical)
* null bytes/chars are accepted by neither postgresql or cassandra

Update to upstream version '2.6.3'
with Debian dir 216fcda7a93684ee59ff01a0c7f8fc6021ad0e72

This is the only value we should use from now on;
and the value is ignored by swh-storage anyway.

Update to upstream version '2.6.2'
with Debian dir df6eb8e5ae3566559bfc86ac892acd3504dc130b

It will be used by swh-web.

Closes T3393

Update to upstream version '2.6.1'
with Debian dir de4cc1005c62c873540e9c8b8067233771377a1f

- add typing annotation to avoid such error in the future

Fixes T3383

Update to upstream version '2.6.0'
with Debian dir a5928cf48b5ed5e74f56196c93fd182d82f7589a

the problem was for datetime<epoch, the timestamp is negative, but since
it's a float that includes the microseconds, if both are true (< epoch
and microsecond > 0), then the computed (int) timestamp was off by one.

Add dedicated tests for this.