SDK selection refactor

[lyoshenka]

here's how I want to make wallet selection work:

• request comes into the proxy handler
• if user is not authenticated (aka does not have a verified email), they get a random sdk
• if they are authenticated but don't have an sdk assigned in the database, they get assigned the least-loaded sdk (and that's saved in the db)
• if they do have one assigned, they get the one they have
• all this logic happens in one place, either in a middleware or in a function that can be called to get the Caller. it should work the same way for proxy calls as for publishing (right now there are two slightly different paths)

i'm planning to drop the wallet_id column in the db, and most references to wallet ids in the code. sdk assignment will be done off user ids, and anytime wallet ids are needed, they'll just be generated from a template (right now that's lbrytv-id.ID.wallet)

other changes i made:

• dropped the Caller interface in favor of just using the real type. i get why it was necessary (for mocking the rpc client during testing), but we don't need that anymore because I ...
• rewrote tests to use a real jsonrpc server so we don't need to mock that anymore. and by real, i mean a server running in a separate thread that's created/destroyed for each test. look at internal/test/test.go if you're interested in how that works. it works equally well for mocking http servers

This is a continuation of the work in #195

[anbsky]

Thanks for this refactoring effort, many places required cleaning up. In general feels like it's more maintainable now.

[anbsky]

Maybe it's just me, but I like to keep any views logic, no matter how trivial, in the handlers source file to minimize surprises in code discovery.

[lyoshenka]

what do you mean surprises in code discovery?

[anbsky]

The kind of surprise when you read through handlers.go and realize that some of the handlers logic is actually in routes.go

[anbsky]

Coverage decreased (-1.1%) to 63.347% though

[lyoshenka]

a lot of unused functions in config.go. can i delete them?

[anbsky]

a lot of unused functions in config.go. can i delete them?

I think they're mostly from player code so yes.

[anbsky]

Returning variables of private types from public functions is not a recommended practice

[lyoshenka]

can you link me to where this is not recommended? i see this in plenty of places and it makes sense to me

[anbsky]

I learned this from golint and their reasoning seems compelling, namely:

can't put a *sample field in their own struct

Even in my not-so-long practice I distinctly remember being annoyed by this more than a few times.