feat: request action validation framework created, and implemented on sign and submit endpoint

[lchen-2101]

closes #482
closes #515

new context, and validation dependency concept, currently only applying to the sign endpoint, can extend to additional endpoints.

also removed some of the tasks code since we no longer going with that concept; allowing for some daos to not be detached.

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
src/sbl_filing_api
config.py
src/sbl_filing_api/entities/models
dao.py
src/sbl_filing_api/entities/repos
submission_repo.py
src/sbl_filing_api/routers
filing.py
src/sbl_filing_api/services
request_action_validator.py					43, 56-57
Project Total

This report was generated by python-coverage-comment-action

[jcadam14]

First thank you for cleaning up the task_actions! Left it in there just in case we revisited it but think that ship has sailed.

If someone fat fingers a validation function or adds one to the list without adding the corresponding impl what happens? Might be good to add a check and error gracefully?

[lchen-2101]

First thank you for cleaning up the task_actions! Left it in there just in case we revisited it but think that ship has sailed.

If someone fat fingers a validation function or adds one to the list without adding the corresponding impl what happens? Might be good to add a check and error gracefully?

at the moment, a non-existent check gets ignored, so it still runs through the remaining existing checks; although I should definitely at least log it.

[jcadam14]

First thank you for cleaning up the task_actions! Left it in there just in case we revisited it but think that ship has sailed.
If someone fat fingers a validation function or adds one to the list without adding the corresponding impl what happens? Might be good to add a check and error gracefully?

at the moment, a non-existent check gets ignored, so it still runs through the remaining existing checks; although I should definitely at least log it.

Ok yeah I see where you're filtering now. So yeah I think that would be the only thing I would add here. Seems like if there is supposed to be a check we want to do, as configured by the environment, but we don't actually have that check we'd want to flag it somewhere. Not sure if that should fail validations? Doubt it's a case we'll come across a lot.

[jcadam14]

Ok I think this looks good, I'm sure we'll iterate over stuff as it actually comes up.

Do we need an update to the configmap?

[lchen-2101]

Ok I think this looks good, I'm sure we'll iterate over stuff as it actually comes up.

Do we need an update to the configmap?

yeap, configmap will need to be updated; also api-commons, if we all are good with this route, the regtechexception needs to be able to accommodate a list; right now it's just a string repr of the list.

[jcadam14]

Looks good. Hopefully will come into play for more endpoints in the future

[lchen-2101]

Looks good. Hopefully will come into play for more endpoints in the future

Yeap, I think some endpoints can leverage this already, will get a ticket created and check them out.