Improvement: add source user and type to tasks and deployments

[shreddedbacon]

General Checklist

• [ ] Affected Issues have been mentioned in the Closing issues section
• [ ] Documentation has been written/updated
• [ ] PR title is ready for inclusion in changelog

Database Migrations

• [x] If your PR contains a database migation, it MUST be the latest in date order alphabetically

Track the user or system that triggered a task or deployment. It adds sourceType and sourceUser to Task and Deployments which can only be set when the tasks are created initially. These fields cannot be modified afterwards (beyond direct database interactions)

The two trigger types are API and WEBHOOK. Deployments currently support both source types. Tasks are not triggered by webhooks, so only the API type is available to it.

The webhook source type will also try and extract information about the user that initiated the webhook call if possible, otherwise the trigger user will just be webhook.

API source types will try and retrieve the user email address from the token, if the user triggering the task is a system token, it will extract the iss field from the system token, this could result in strange names if a token is really old.

This does not backport the data to existing tasks/deployments as this information is unknown, so the data will be null for old tasks and deployments. The thought of adding an UNKNOWN type with it being the default, so historical fields would be UNKNOWN type. The source user could also default to unknown if not provided. Rather than being a null field.

Closing issues

closes #3144 partially #1980 (better audit capability in lagoon needed generally)

[shreddedbacon]

I've added some basic tests to the test suite to check that the fields are populated when deployments are triggered via webhook and api calls both git push and pullrequest, deployenvironmentlatest, and deployenvironment branch.

[shreddedbacon]

the promote test still seems to use a test-suite legacy token, when other tests uses a ci user token, this can be resolved in a separate PR though