Create a new Ready Session

[sgomez]

Basic flow.

1. A new Ready Session is requested (GetReadySessionQuery).
2. A service connects with the backend and wait for an answer (qr code, jwt token and readySession identification).
3. The service returns the ReadySession entity.

Extensions:

1. Server is not available
   1. Returns a connection exception
2. Authorization is revoked
   1. Returns a authorization exception

Preconditions:

1. The system must be configured with this static information: opaque-id (as client identification), url endpoint, TTL request, auth token.

Postconditions:

1. We don't need to persist the information. The same data will be received after session was completed. (we can discuss this point).

[MKodde]

The issue or story, whatever we call it, looks good @sgomez!

Some feedback:

1. Maybe an additional precondition would be to have received a SSO request from the remote SP?
2. On our Slack channel you mentioned you want to implement this utilizing commands. I recon you want to use the CQRS (Command Query Responsibility Segregation) principle? Or am I jumping to conclusions here. I for one would like this implemented. Note that I do not propose to implement a fully-fledged event sourced system. But simply keep the read and write sides of the application strictly separated.
3. Have you thought about the test coverage for this issue?

[sgomez]

1. IHMO that is an infrastructure precondition. Should be checked in the controller. I want to start to implement the commands/services that will be called by the controllers.

2. I'm thinking just in the regular Command Pattern with the messenger symfony component. CQRS implies a read model and a write model. But we can assume than ReadID backend is read model and our cache is write model. I use the same verbs than CQRS (Query and Command) just because are very verbose about the action we want to do.

3. Sure, commands unit test are trivial. Services tests (the ones than connects with the READid endpoints) can be implemented mockering the HTTP client.

[MKodde]

1. OK
2. We are on the same page then. Having the strict seperation is not that usefull at this stage and making the intent of the commands and services verbose will be sufficiently clear for sure!
3. Perfect. We could consider adding acceptance (e2e) tests using Symfony Panther or Behat. But might not prove that usefull. Let's see how this turns out. If we find we are fighting regressions, we can always write a couple of acceptance tests.