concord-server: assert user enabled before process restart or handler

[benbroadaway]

Some scenarios do not currently check if the current user or initiator is enable/disabled.

1. Browser sessions
   1. User can continue browsing, but may hit other access errors if/when they attempt to modify a resource or start a process
2. Final-status processes which are restarted (checkpoint or runtime-v2 restart) by another user
3. Forked child processes. including normal forks and on-handler forks
   1. Regularly forked flow should usually catch the disabled user on the API request to fork, but if the user happens to be disabled after the request, and before the process starts executing, then it may continue executing
   2. on-handler forks are not initiated by a direct API call, so they need a specific check

A specific example: a user sets up an automation that continuously starts hundrds/thousands of processes across many repos with onCancel and onFailure handler flows. Admin permanently disables the user to stop impact of new processes, and cancels everything that's been started (either via UI, REST API, or a direct DB current_status update). The process watchdog task in concord-server will continue to generate new onCancel forks until it's satisfied. If those forks fail or are also cancelled, the watchdog continues generating more until the default max of 3 attempts is reached for each parent. An oopsie of 10,000 processes can explode to 40,000 total.

A tangential thought: add a cancel process option that disables the onCancel handler if it exists?