date field in 'changed:' attribute not enforced, perhaps replace with "last-modified+created:"

[job]

Describe the bug
The RPSL changed: attribute should be forced to today's date (format: 20201230 when an object is submitted to an authoritative database.

To Reproduce
Sent an rpsl email, forgot to fill in the date field in after changed: job@ntt.net. Expected it to be filled in by the IRRd itself (that is what v3 did)

Expected behaviour
changed: job@ntt.net should have ended up in the db as changed: job@ntt.net 20200313

But given that we now have an opportunity to improve, perhaps what is better is to strip the changed: attribute from the object and replace that functionality with last-modified: and created: like is done in the RIPE NCC DB.

https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-ripe-database

IRRd version you are running
4.0.8

Additional context

job@vurt ~$ date
Fri Mar 13 21:14:28 UTC 2020
job@vurt ~$ whois -hrr.ntt.net 45.138.228.0/24
route:          45.138.228.0/24
descr:          Job Snijders - rpki not-found
origin:         AS15562
mnt-by:         MAINT-JOB
changed:        job@instituut.net
source:         NTTCOM

[mxsasha]

We did do some work in this in #242, I'll look into it.

[mxsasha]

In #242, we indeed implemented exactly this behaviour, so it should work. However, there is a limitation if the changed line was already present: changed lines that were present in the existing version of the object, should be left untouched.

@job: We can also go for disallowing changed for new objects, and implement last-modified and created attributes. Those would be automatically filled by the database. IRRd does have limited information on the creation date: we know when the object showed up in the SQL database, but from a user's perspective, it may be much older.

All this would only apply to authoritative objects, objects from mirrors are left as is.

[mxsasha]

Discussed with Job:

• we're moving to implement last-modified, even though it has limitations as IRRd can not look in time before it's SQL database was created
• last-modified should be in the dumps as well
• created will not be implemented
• IRRd should take no action on changed lines, they are left as submitted

I need to look into last-modified in combination with RPKI, desirable is that RPKI status changes do not affect last-modified.

This only applies to authoritative objects, objects from mirrors are unchanged.