Re-authorize farms

[paul121]

Once a farmOS server is migrated to farmOS 2x, the access token the Aggregator has will no-longer be valid. This is because the oauth2_server and simple_oauth modules used in the farmOS server use different token formats (oauth2_server uses a simple fixed length random string. simple_oauth uses an encrypted JWT).

We could investigate a way to migrate the access tokens... but my initial thoughts are it isn't possible without modifications to simple_oauth internal validation of tokens. This seems unnecessarily complicated since we have other alternatives (and not many users of the Aggregator).

For the "managed aggregator" use case (where credentials to a user account is known for all connected farmOS servers), a simple re-authorization script should be sufficient in providing Aggregator farms with a new, valid access token.

For the use case where farmOS admins have joined an aggregator themselves, the admin will need to re-authorize their farmOS server with the Aggregator. This requires communication between the Aggregator admin/farmOS admin during the farmOS server migration. Since we already have methods in place to request authorization from farmOS admins, I consider this use case handled.

Changes to OAuth scopes should be taken to account during this process: #105

[paul121]

I've updated the /api/v2/utisl/authorize-farms/{farm_id} endpoint to work for both 1.x and 2.x servers. This endpoint is used when re-authorizing an existing farm via the UI.

I tested adding and authorizing a 1.x server on a local URL. Then, I brought up a 2.x server on the same URL (simulating the update process). Making a request with the old token failed - as expected. I was then able to re-authorize the server via the manual Authorization Code flow. This should cover the use case described above where a "manual" re-authorization is required.

For the "managed aggregator" use case (where credentials to a user account is known for all connected farmOS servers), a simple re-authorization script should be sufficient in providing Aggregator farms with a new, valid access token.

This process shouldn't be affected by any of these 2.x changes. This script will just send a PUT request that manually updates the token (and likely scope) associated with a farm. Once updated, the existing farm will be good to go.