feat: Add Credential Offer initial support

[sebastianopriscan]

Short description

This PR solves WLS-123 by adding a first implementation for Credential Offer based issuance. While the flow is working, and credentials can be obtained, through offer QR Codes / Deeplinks, it doesn't fully comply to the ITW specification for the following reasons:

• The scope and issuer_state field in the credential offer's authorizationgrant are not forwarded to the PAR. (While the SDK partially supports it, io-react-native-wallet does not, more on that later).
• The authorization_server field isn't double checked against the issuer's Entity Configuration.

Being that these issues are not blocking PARI integration PoC, I think that for the moment it would be better to wait for them to be patched in the original packages and then integrate them into the App, let me know if you agree.

List of changes proposed in this pull request

• Due to React Navigation not being able to differentiate deeplinks by scheme, the deeplink management subsystem has been refined by:
  • Moving the deeplinking store to the navigation lib, so that both the main app and the mini-apps can access it
  • Making the storage of the deeplink url mandatory (so now it is stored in any case, not only when navigation was not mounted/ready).
  • Demoting the PresentationPreDefinition screen from being the deeplink receiver: now that role has been taken by a specialized DeeplinkHandler screen that parses the URL and decides which flow to trigger (presentation or issuance).
• Made the DeeplinkHandler screen process QR Code URLs, too.
• Added a new linking path for the credential offer flow which handles offered credential issuance with eventual Wallet activation.

How to test

The tests from the following matrix have been performed successfully on both an Android Device and iOS Simulator.

Start	Engagement	Has PID	Has Cred	Flow Type	Expected
Setup	Deeplink	No	No	Issuance	After selecting the App the user obtains both PID and Cred
Setup	Deeplink	No	No	Presentation	After selecting the App the user is only prompted to activate the Wallet
Cold	Deeplink	No	No	Issuance	After opening the App the user obtains both PID and Cred
Cold	Deeplink	No	No	Presentation	After opening the App the user is only prompted to activate the Wallet
Cold	Deeplink	Yes	No	Issuance	After opening the App the user obtains the Cred
Cold	Deeplink	Yes	N/A	Presentation	The user proceeds with the presentation
Cold	Deeplink	Yes	Yes	Issuance	A screen telling the user the credential's been already obtained pops up
Hot	Deeplink	No	No	Issuance	The App navigates to PID issuance, then it proceeds with the Credential issuance
Hot	Deeplink	No	No	Presentation	After opening the app the user is only prompted to activate the Wallet
Hot	Deeplink	Yes	No	Issuance	The App navigates to Credential issuance
Hot	Deeplink	Yes	N/A	Presentation	The user proceeds with the presentation
Hot	Deeplink	Yes	Yes	Issuance	A screen telling the user the credential's been already obtained pops up
Hot	QR	No	No	Issuance	After scanning the QR the user obtains both PID and Cred
Hot	QR	No	No	Presentation	After scanning the QR the user is only prompted to activate the Wallet
Hot	QR	Yes	No	Issuance	After scanning the QR the user obtains the Cred
Hot	QR	Yes	N/A	Presentation	The user proceeds with the presentation
Hot	QR	Yes	Yes	Issuance	A screen telling the user the credential has already been obtained pops up

Where the State fields mean the following:

• Setup : The user has not chosen the mini-app yet.
• Cold : The app was not started (not even in background).
• Hot: The app was started but in background.

The Has Cred column is related to the case in which the wallet already contains or not the credential in the offer / required for presentation. The presentation scenarios in which the Has Cred field is N/A could not be tested due to lacking a 1.3.3 aligned RP.

To test the QR Code credential offer, the following code can be used.

Depends on: #189 .

[github-actions]

PR Title Validation for conventional commit type

✅ All good! PR title follows the conventional commit type.