* feat(task): impersonate user on task execution
Passing tokens to tasks is cumbersome and we needed a way to more easily create tasks. With this change we no longer need a token on task create. We take the user that created the task and pass that in as the "owner". As far as the task is concerned the owner is the source of permissions.
This is done by adding an additional field on task create that is OwnerID. We will no longer respect the token passed in and it will be deprecated soon.
Things to do still:
Task updates need to allow for owners to be set.
In the platform adapter, we ask the URM for a list of tasks the user
owns, and then we look up each task individually.
The task service tests uncovered a legitimate bug where FindTasks would
return a "task not found" error, originating from looking up a task that
was present when we interrogated the URM but was deleted before we could
find it in the task store.
This change also removes duplicated URM logic from the HTTP handler
which has since been pushed down into the platform adapter.
The query system specifically expects an Authorization. When a request
comes in using a Session, use the target task's Authorization, if we are
allowed to read it, when executing a query against the system bucket.
Also set the generated token's description while we're here.
This enables us to use task's Authorization when we need to query the
system bucket to get run logs, etc. but we only have a Session.
Task ID is now a required value on run and log filters. It was
effectively required by all implementations before anyway, so now those
types reflect that requirement.
Organization ID was removed from those same fields. The TaskService
looks up the organization ID via the task in cases where we need it at a
lower layer.
With the ongoing authorization work, creation arguments will differ from
what's returned on reads. More specifically, creation will accept a
token, but reads will report back a token ID.
This refactor facilitates that authorization work, and also brings the
code closer to the swagger definition, for the TaskCreateRequest type in
particular.
For an operation that looks up a task or a run, when that operation
fails, only set the status to 404 if that operation explicitly returns
ErrTaskNotFound or ErrRunNotFound.
It's possible that the operation could fail for a reason other than the
ID being invalid: for example, if there was an IO error preventing the
lookup from succeeding.
Harden that behavior with tests for the task handler.
Closes#11589.