[API] Collapse SP/CP/MyInfo login endpoints to new /api counterpart

[karrui]

This issue tracks the collapsing of /spcp, /myinfo related endpoints to their new /api/forms/:formId/auth counterparts.

The current /spcp routes require the client to pass in information such as the target endpoint, the current authType, and the esrvcId of the current form. However, all this information should be retrieved from the backend itself, and the new endpoint should only accept formId as a parameter, like the current /myinfo routes for consistency.

This also allows for the form's authType to be obtained from the form referenced by its id, which is the SSOT.

Collapsing all the various endpoints to just two endpoints (/redirect and /validate) also allows for less code to maintain and increases the consistency in the APIs.

The old endpoint should not be deleted for backwards compatibility (at least for a few weeks after the new endpoint has been released).

The current to new mapping is shown below:

#	Existing endpoints	New endpoints (note that all routes are prefixed with /api/v3)	Description
20	GET /spcp/redirect query: { target, authType, esrvcId }	GET /forms/:formId/auth/redirect	redirect to SPCP endpoint to login
21	GET /spcp/validate  query: { target, authType, esrvcId }	GET  /forms/:formId/auth/validate	gets the spcp redirect URL and parses the returned page to check for error codes
22	GET /myinfo/redirect query: {formId}	GET /forms/:formId/auth/redirect
23	GET /myinfo/validate query: {formId}	GET /forms/:formId/auth/validate

[seaerchin]

@karrui clarifications on this issue: this is actually a few things right?

1. collapse spcp
2. collapse myinfo
3. migrate to new router

[seaerchin]

@karrui should we omit the formId query parameter since it is already part of the url path?

[karrui]

@karrui should we omit the formId query parameter since it is already part of the url path?

good point, yea no need thanks for the catch; but add persistantLogin query param, to be used by spcp auth