Add UI for generating long lived access tokens

[balloob]

Allow people to generate access tokens that live for a long time. That way they can update their old scripts that take api_password and still make them work.

[awarecan]

Some thought

Front end

1. User can list/add/remove long-lived access token in profile page, the term can be simplified as "Access Token", user can only do it on its own behalf
2. User can name the access token (and/or long text field for description), do not allow name starts with http (also https), or maybe we can directly use client_id as the term.
3. User can determine how long the access token's live (1 day - 3650 days?)
4. Optional User can re-generate access token, which will invalid exist access token associated with same name
5. Optional The access token only display once,

Back end

1. Allow create refresh_token with different access_token_expiration,
2. Use client_id field store access token name field, if client_id not starts with http, means it is name field inputted by user, therefore it is not a valid IndieAuth client_id, no login allowed.
3. Each such client_id can only have one refresh_token, each such refresh_token can only have one access_token generated, After access_token generated, a marker filed should set to True, or use 'last_access_token_generated_at` timestamp
4. User revoke or regenrate "Access Token" from UI, it will delete refresh_token
5. access_token generate, validate and revoke login do not need change, a directly expose of remove_refresh_token might be need.

@balloob I am going to start it from back end implementation, let me know if you any comment

[balloob]

We should not abuse the client ID field to either be a name or url. We should add a name field instead. We can default the name field to be the client_id for normal tokens for now, in the future we might want to support apps passing in name as per the IndieAuth spec.

The refresh token for long lived tokens need to be a special "type", that will allow only a single access token to be active. To ensure only a single access token is active, whenever a new one is generated, the refresh token needs to also generate a new jwt key. That way the old access token will no longer work.

[awarecan]

Per 4.2.1 Application Information, application has name and/or icon information, two extra fields will be added to refresh_token.

[awarecan]

Changed design

Back end

• Allow create refresh_token with different access_token_expiration,
• Add client_name, client_icon fields
• Add token_type, normal, system or long_lived_access_token
• Each such client_id can only have one long_lived_access_token type refresh_token, each such refresh_token can only have one active access_token generated. Such refresh_token will mutate jwt_key before generate access token, therefore only one access token is valid at one time.
• User revoke "Access Token" from UI, will delete refresh_token
• access_token generate, validate and revoke do not need change, a directly expose of remove_refresh_token might be need.

[balloob]

We already have a revoke token support on /auth/token, although it doesn't currently work based on IDs, you need to send the token (and we wouldn't want to send all the tokens to the frontend).

[awarecan]

I think this issue can be closed now.