Move parts of the project over to `rivershared`

[brandur]

As discussed over Slack, we've been having trouble wherein we often find ourselves needing pieces of the main River Go project over in other projects like River UI, and having to copy a bunch of stuff over.

Here, we establish a new rivershared repository in [1], then move references to it in the main repository over.

Basically my methodology for this one is that I'd been working on the plugin system, wanted to see if startstop.Service could be moved so we didn't have to duplicate it in rivertype, moved it to rivershared, then moved all of its dependencies over to rivershared as well. (Most of these dependencies come from startstop's test suite.)

[1] https://github.com/riverqueue/rivershared/pull/1

[brandur]

@bgentry Is this roughly what you had in mind?

One note here is that I didn't move any of the database stuff, although we may want to do that as well to get things like TestTx for River UI's test suite as well.

The downside is that it's definitely way more annoying to make updates in another repo when that's necessary. I think there's a strong possibility that this should be another Go module in a subdir of the main River project instead. It's still another module, but all the main River code gets to use replace directives, which does help make updates a lot less painful. Another module is annoying, but we already have pretty good scripting for working with many modules here, so not sure it'd make much practical difference.

I think I've talked myself into a 60% preference for keeping things in a monorepo (i.e. as opposed to what's shown in this PR), and then detaching to a separate repo if there's a good reason for it. What do you think?

[bgentry]

@brandur I’m fine with putting it in another sub module if you think that’s better or easier. Nudges us just a little more toward wanting to further automate the release process, but we should probably do that soon enough anyway.

[brandur]

@bgentry K cool, let's try the monorepo version to start then, and see how that goes. Opened #429.

And yep, definitely +1 on getting that release process automated at some point.

FWIW, when I'm cutting a release I just dump all the commands into my shell at once instead of running one by one. Not perfect, but works well. e.g.

    git tag riverdriver/$VERSION -m "release riverdriver/$VERSION"
    git tag riverdriver/riverpgxv5/$VERSION -m "release riverdriver/riverpgxv5/$VERSION"
    git tag riverdriver/riverdatabasesql/$VERSION -m "release riverdriver/riverdatabasesql/$VERSION"
    git tag rivershared/$VERSION -m "release rivershared/$VERSION"
    git tag rivertype/$VERSION -m "release rivertype/$VERSION"
    git tag $VERSION