[ENHANCE] Implement V2 UI (expiry, custom args, rules/groups)

[lachlanglen]

Summary

See V2 contract interface. This is currently deployed to v2new.staging.nadabot.near and has been populated with data from production. Current contract admins are plugrel.near, lachlan.near, wendersonpires.near & carina.akaia.near. As an admin you should be able to make any necessary write actions in order to test the UI.

See V2 designs - see DEV NOTE comments for clarification & feel free to add additional comments in Figma, comment on this ticket or post in TG for any additional clarification!

_A note on terminology: "provider" and "stamp" are almost synonymous - a provider is essentially a stamp definition, and a stamp is an individual instance of that provider that is attached to a user, and records the timestamp of when the user verified this stamp. As a user, there are two steps to getting a stamp. The first step is to go to the provider's URL (Provider.external_url) and complete the requirements to obtain their stamp (e.g. connect your twitter, scan your face, fill out your NEAR Social profile etc). This adds a record on the provider's contract, and then the user must add the record on the Nadabot contract by calling add_stamp(). This method verifies that the user has the target stamp, and adds a record as such to the Nadabot contract._

Description

Overview:

The Nadabot V2 contract adds a few new concepts:

1. Expiry

stamp_validity_ms has been added to the Provider struct, which gives admins the ability to expire stamps. When one of the humanity methods is called (e.g. is_human or get_human_score), the timestamp of the user verifying the stamp is compared to the current block timestamp, and if the delta is greater than Provider.stamp_validity_ms then the stamp is considered to have expired and will be ignored. A user can always reverify their stamp once it has expired (or before it has expired, if they wish).

2. Custom args

In V1, providers were required to implement a contract method with a signature that adhered exactly to our specification (accepting a single argument named "account_id", and returning a boolean). However, this did not provide adequate flexibility to providers, so we have adapted this slightly, allowing custom (but hardcoded) args that are stored on the provider (Provider.custom_args) and are added to the args map at the point of verification. Use cases include SBTs where a "class" might be required, or a social verifier that requires a platform arg like lens or farcaster.

3. Groups/Rules

A group is a collection of providers, and a rule is a required element of a group which indicates the relationship between providers in the group, and how a user's score changes if they hold more than one stamp in that group. There are currently 5 types of rules, as outlined here.

Even though technically speaking a rule belongs to a group, the rule (not the group) is the primary user-facing entity. So "rule" and "group" are quasi-synonymous from a user's perspective. Rules affect a user's score, and are a tool that contract admins can use to tweak humanity scoring to incentivize desired behavior and disincentivize botting.

Blacklisting is also added in nadabot v2, but will be implemented in a separate ticket.

Acceptance Criteria

[List of criteria that must be met for the enhancement to be considered accepted]

Additional Information

[Any other relevant information, such as links to related issues or pull requests]

[carina-akaia]

@lachlanglen just to clarify: is "admin's comments" functionality within the scope of this story?

[lachlanglen]

@carina-akaia yes, if you can add that would be appreciated. There will be a few little things like this that are not entirely related to V2 but are some elements that were missed in V1. Thanks!

[lachlanglen]

@carina-akaia I split out blacklisting into a separate ticket - see here