Drop rescuer check on unknown job kind

[brandur]

Drops the check the job rescuer on unknown job kind. This allows
multiple independent Rivers to operate together within a single schema
because when they do, they all share a single elected leader, so that
leader has to be able to work on behalf of all of them.

See discussion in:
#1105

[magaldima]

@brandur are you worried that jobs that become orphaned (no client is configured with them anymore) will not get any attention from clients. You brought this up in a previous comment in #1105. Would this mean that you could have jobs stuck in a retryable state forever which are never worked? Curious if we can re-use the river config's SkipUnknownJobCheck flag here since the use case for job insertion and rescuing via a leader is similar.

[brandur]

Yeah :/ After talking this through, I don't think it's the way to go after all. The major problem is that in case a job kind has a custom retry policy (which may exist only on a different client somewhere), it wouldn't be adhered to properly.

Something with SkipUnknownJobCheck seems plausible, although I'd worry there that we'd keep selecting out the same jobs to rescue and then ignore over and over in cases where there wasn't another client out there to handle them.