Store ASN with IP addresses ; add ability to restrict based on ASN

[diox]

Fixes https://mozilla-hub.atlassian.net/browse/AMOENG-2549
Fixes https://mozilla-hub.atlassian.net/browse/AMOENG-2550

Description

This adds ASN data to IPLog whenever we store ip addresses (provided by Fastly through the Asn header).

This also adds a way to restrict requests and/or auto-approval from their ASN, similar to what we already have for email or IP addresses, as well as admin tools to manipulate that data.

Context

Like IP addresses and other metadata, we have to store that on the FileUpload inside request_metadata at upload, to then override whatever the current thread has when we create the final Version, in case that version is created in a task.

This then allows not only IPLog to be created with the correct value, but also the restriction stuff to use that metadata for auto-approval restrictions.

Testing

Locally, you'll have to uncomment the addons.conf.template bit to pass an hardcoded Asn header to your requests and restart nginx. From there:

• Submitting an add-on through any mean (API, devhub) should record the Asn in IPLog together with your IP address.
  • Same with any other activity defined with store_ip = True on the activity constant class
• If there is a restriction for that ASN in the admin (users > Asn user restrictions) it should affect submission or auto-approval depending on what is set

[diox]

As with JA4 this can be uncommented to test locally.

[eviljeff]

(going to test, just submitting my comments in the meantime)

[eviljeff]

does iplog__asn work here? (I'm going to keep asking until we can actually make use of that new feature 😆)

[diox]

I tried! Unfortunately I had to revert that, because it turns out such lookups are not allowed in fields or readonly_fields, only list_display. It raises a system check error if you try.

Documentation for fields says:

The fields option accepts the same types of values as list_display, except that callables and __ lookups for related fields aren’t accepted.

[eviljeff]

Have we gone through everywhere an existing task might need to do this?

I'm aware it's existing functionality, but it feels fragile to put the onus on each task, when the code that actually saves the activity log may be a few methods abstracted from that task. (I don't have an immediate suggestion how to address this)