Search backend: move map logic to job interface

Created by: camdencheek

Okay, this is the last step to break the cyclical import issues. This makes job.Map operate on the Job interface with a new MapChildren() method rather than unwrapping into every possible job type.

Stacked on https://github.com/sourcegraph/sourcegraph/pull/38353

This is nice for a couple of reasons:

1. It breaks hard dependency links. Right now job/jobutil imports every package that defines a job, which causes a hotbed of circular import issues.
2. It means jobs never need to be enumerated. Everything you need to know about a job is captured by its interface, and you only need to name the type you're unwrapping to. This means you can use Map without ever importing internal/search/job/jobutil.

Test plan

Unit tests. All existing tests passed, and I checked that there were a number that exercised current mapping behavior.

Created by: rvantonder

Review: Approved

Happy for you to take on the restructuring, thanks!

Disgruntled that in Go I can't look at a single function to understand how it maps/visits a tree. Such is life.

Merged by: camdencheek at 2022-07-08 01:07:05 UTC