Removed futures from controller (#33)

[TheLydonKing]

Release Notes:

• Removed Futures from all return types of the token controller
• Amended Tests and classes required for this

closes: #33

[github-actions]

Report: Report: api - scala:2.12.17

Metric (instruction)	Coverage	Threshold	Status
Overall	66.86%	43.0%	✅
Changed Files	65.7%	70.0%	❌

File Path	Coverage	Threshold	Status
PublicKey.scala	57.89%	0.0%	✅
PublicKeySet.scala	57.89%	0.0%	✅
TokenController.scala	81.31%	0.0%	✅

[dk1844]

LGTM in terms of complying with the task of removing the future.

I am thinking if we ever need to introduce futures for specific reasons, if this poses a problem -- I assume we can block/await for those or create specific endpoints.

Having futures in IO/web appcode always seemed natural, but I am willing to give this a try and see where it leads us.

[dk1844]

what is the point of removing AnyVal here?

[TheLydonKing]

For some reason, having the anyVal had the json be encoded as "BASE64ENCODEDSTRING" instead of {"key":"BASE64ENCODEDSTRING"} and creating an issue when a Future is not being used.

[TheLydonKing]

LGTM in terms of complying with the task of removing the future.

I am thinking if we ever need to introduce futures for specific reasons, if this poses a problem -- I assume we can block/await for those or create specific endpoints.

Having futures in IO/web appcode always seemed natural, but I am willing to give this a try and see where it leads us.

I agree with this but I think in our case it may be redundant because our service and authentication layer isn't using Future or IO so it ends up being synchronous anyway and just adds overhead.

If we want to reimplement futures, it would probably be a bigger task of rewriting our services and authentication modules to be asynchronous.