fix(routing): mediation recipient role for recipient

[TimoGlastra]

Mediation role was being set to MediationRole.Mediator instead of MediationRole.Recipient. This pr fixes the incorrect role, and adds checks to the methods to make sure we're in the correct context (record.assertRole()).

This is a breaking change, and I'm not sure how to handle this. The record is almost identical between mediator and recipient, so not so sure how to write a migration script for this. As most devices are run inside a specific context (only mediatee or only mediator) the easiest way to update would probably be to update all records to a certain role.

@JamesKEbert heads up on this one. Please let me know how you would like to approach the migration of this. Due to the assertions of the role this is going to cause errors in wallets created before this PR.

Also does some clean up and refactoring

BREAKING CHANGE: for mediation records, the role was being set to MediationRole.Mediator when acting as a recipient. This is updated to the correct value MediationRole.Recipient.

[codecov-commenter]

Codecov Report

Merging #661 (5845d12) into main (d1049e0) will increase coverage by 0.18%.
The diff coverage is 62.96%.

@@            Coverage Diff             @@
##             main     #661      +/-   ##
==========================================
+ Coverage   85.72%   85.90%   +0.18%     
==========================================
  Files         340      340              
  Lines        7333     7328       -5     
  Branches     1140     1140              
==========================================
+ Hits         6286     6295       +9     
+ Misses       1046     1032      -14     
  Partials        1        1              

Impacted Files	Coverage Δ
.../src/modules/routing/repository/MediationRecord.ts	78.57% <25.00%> (-12.61%)	⬇️
...ules/routing/services/MediationRecipientService.ts	76.33% <77.77%> (+2.85%)	⬆️
...re/src/modules/routing/services/MediatorService.ts	87.50% <80.00%> (+14.50%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d1049e0...5845d12. Read the comment docs.

[JamesKEbert]

I took a look at this--we could possibly use the endpoint field on the record to be able to determine if they've successfully created a connection to a mediator with this record (as the endpoint is not set when running as a mediator). The only case I could see maybe being problematic with this is if the mediation grant hasn't actually occurred (meaning the endpoint is not set), however the mediator is not able to be used anyway at that point, so it's likely already in an error state.
So, it might still be safer to allow the end developer to indicate what they want the new records role to be (as we discussed on the AFJ call, since use cases right now are only doing one or the other role, but not both).

[TimoGlastra]

Thanks for this James, this is really helpful. I've added a few options to the upgrade allMediator, allRecipient recipientIfEndpoint and doNotChange. This will allow the user to choose what upgrade path to choose. I'm however still thinking about what would be the best default option? I don't want to use doNotChange because that can leave it in a broken change (should this even be an option?). But the others can also have implications. Maybe we should make it a required configuration parameter? I would like to give all upgrade parameters a default value as it makes it a lot easier (no need to deal with missing required params)

[TimoGlastra]

Merging for now, will add the record upgrade script in the upgrade assistant soon