Add Developer Agreement API

[chrstinalin]

Fixes mozilla/addons#16377

Description

Adds developer agreement API.

Testing

At endpoint api/v5/developers/agreement --

• Can GET to retrieve last_developer_agreement_change. Returns 200.
• Can POST with display_name and last_developer_agreement_change to accept, if a) agreement was updated since the previous accept, or b) have not yet accepted before. Returns 202.
• Otherwise returns a 400.

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• The change is covered by automated tests, or otherwise indicated why doing so is unnecessary/impossible.
• Add or update relevant docs reflecting the changes made.

[diox]

I think we'll want two three things here:

• Something to prevent users from scripting their way around the agreement too easily. Maybe a simple GET API (requiring auth) to retrieve the date the agreement last changed (see implementation for has_read_developer_agreement()) and force them to pass that exact value via POST ?
• Rate limiting (on both endpoints if going that route)
• Checking RestrictionChecker(request=request).is_submission_allowed() and returning a 400 with the error message if the user is not allowed to submit, like render_agreement() currently does

[nothingrandom]

I think this feedback is targeted more towards the ticket itself than this work, but this doesn't match what I had in mind (and again, we should have fleshed this out better - one for a team retro imo).

Feel free to turn this into a proper discussion, I might have misunderstood things.

My expectations (these are just examples, I haven't validated these are real);

http:post::
  :>json string user_uuid: something unique to identify the user with
  :>json string accepted_agreement_version: version of the developer agreement accepted (or YYYY-MM-DD)
  server inferred; UTC date developer agreement accepted

http:get:: (should be public, not internal only per ticket comment from @diox)
  :>query/parameter:>json string user_uuid
  :>returns: is_latest_accepted: boolean
  :>returns: agreement_version: version of the developer agreement  (or YYYY-MM-DD)
  :>optional return (as in I'm questioning the value of this): agreement_content: markdown content of the latest developer agreement

[chrstinalin]

should be public, not internal only

Right now it (and the other API work I've done so far) are generally exclusively using SessionIDAuthentication, i.e. 'internal use'. Making it external is mainly adding JWT auth. Is that more in line with what would be needed? In which case I'd need to update those endpoints as well.

See: #25374 (comment)

[nothingrandom]

@chrstinalin agree on your other comment about user_uuid being extraneous when it's an authenticated request. But from the original, I don't know / understand why you'd want the user display_name?

Regarding internal/external use, I'm basing that requirement on this comment from Mat; mozilla/addons#16377 (comment)

[chrstinalin]

display_name is currently needed when its the first time the user has registered, I ended up modifying the behaviour a bit so that's a bit more clear (there's comments throughout), but you can see it here, for a fresh user:

[chrstinalin]

Regarding internal/external use, I'm basing that requirement on this comment from Mat; mozilla/addons#16377 (comment)

Ahh, right. I forgot to mention. For that, I did see that read_dev_agreement is exposed already through /api/v5/accounts/account/(int:user_id|string:username)/ . So it is possible to get that information via JWT without this endpoint.