Feat/pdjb 260 handle auth and landlord registration during JL acceptance

[JasminConterioSW]

Ticket number

PDJB-260

Goal of change

If the user accepts the invitation, make sure they are logged in and integrate with the landlord registration journey if the user is not already a landlord

Description of main change(s)

• Fix the local-auth profile for local testing
• Modified how the tokens are stored so they are tied to a journeyId (allows multiple journeys)
• Take the token out of the journeyState
• Update getJourneyStep and postJourneyData endpoints so they can't initialise a new journey - we only do this from the startJourney step
• Add an authenticated endpoint after the acceptance step to make the user log in and check if they are a landlord
• If a user is not a landlord, integrate with the landlord registration flow
  • Refactor landlord registration journey
    • Put the bulk of the journey into a task with a new state
    • Move deleting the journey out of the CYA step and into it's own step (so it's not in the task but is in the full Landlord Registration Journey)
  • Add the landlord registration task to this journey and include it for non-landlord users

Anything you'd like to highlight to the reviewer?

• Storing invitation tokens linked to a journeyId
  • Unlike local council user registration (the other place we use invitation tokens), a user could have invitations to multiple properties and start the journeys for them at the same time (in different tabs)
  • I changed the way the tokens are stored to include the journey id so that multiple tokens can be stored in one session
• Taking the token out of the journeyState
  • I had been getting this from the session and passing it into createJourneySteps so it could be initialised
  • But this caused problems if the user got into a cya journey during landlord registration as there was no token tied to the cya journey id
  • We can retrieve the token from the session when required
• Updating the getJourneyStep and postJourneyData endpoints so they can't initialize a journey
  • This is mainly so I don't need the token to initialise the journey again from here - there could be more than one in the session and I wanted to use the journeyId to decide which one to use!
• Integration with landlord registration - I looked at pointing the user to the actual landlord registration journey, but passing them between journeys gets messy (making sure to pass to the correct journeyId)

Checklist

Delete any that are not applicable, and add explanation below for any that are applicable but haven't been done

• Unit tests for new logic (e.g. new service methods) have been added
• Controller tests for any new endpoints, including testing the relevant permissions
• New journey steps have been added to the appropriate journey integration test(s)
• Test suite has been run in full locally and is passing
• Branch has been rebased onto main and run locally, with everything working as expected (both for your new feature
  and any related functionality)
• TODO comments referencing this JIRA ticket have been searched for and removed - if a future PR will address them,
  mention that here
• QA instructions have been added to the ticket (particularly if this is the last PR required to complete the ticket)

[Travis-Softwire]

I think this is mostly fine. I don't love that duplicating the LL registration journey means that we have to expliciltly duplicate the CYA journey structure. I suspect the answer there is to tweak the journey framework to allow reusable CYA journey maps rather than trying to do something clever here via the actual LL registration journey