Close #12870 - Expand the TokenProvision API to include All Token values

[stuntguy3000]

Fixes: #12870

This change allows the TokenProvision API to accept all values applicable to the Token field, providing more user flexibility and use cases.

[jeremystretch]

We should avoid using two different serializers for the same data. Instead, TokenProvisionSerializer should be extended to support the necessary fields.

[stuntguy3000]

We should avoid using two different serializers for the same data. Instead, TokenProvisionSerializer should be extended to support the necessary fields.

My concern here is that if we were to duplicate this serializer, we're introducing two different serializers (with the same non-default constraints) (as shown below), to functionally decode the same conceptual object. This feels like we're duplicating things and making things messy and unclear.

One idea which I think is suitable in this case, is to move away from the TokenProvisionSerializer and replace it with a UserSerializer.

So yes, we're using two serializations, but they're for fundamentally different objects (one for the User, and one for the Token) and we're not doubling up on anything.

Plus, we can't properly validate the Token without the User being valid first anyway.

I've tested this and it works - what do you reckon?