Goal

Today I'll work on using the client context type I made last time in all the subcommands: obnam chunk encrypt, obnam chunk decrypt, and obnam client generate.

Plan

A core problem with the client context is that to use it, you need to have the client key. It's possible to get it from a repository, by trying every credential chunk the configured credentials. I already have code for that.
I'll want another type that can do things that don't require the client key, but also can create the client context. I'll call it LockedClient, and I'll rename the client context to UnlockedClient.
```
struct LockedClient {...}
impl LockedClient {
  fn new(repo: ClientRepository) -> Result<Self, LockedClientError> {...}
  fn unlock(self) -> Result<UnlockedClient, LockedClientError> {...}
}
```
Actually, that could go into ClientRepository. It'll maybe slightly dilute the cohesion of that type, but not so much it's worth another type, I think. The rename of client context is still a good idea, though.

Notes

Added ClientRepository::client_key. This will replace client_key_from_repo in obnam/src/cmd/mod.rs.
Changed obnam/src/cmd/chunk.rs to use the new ClientRepository::client_key method. This was a little more painful than ideal, because the obnam chunk subcommands need to handle the user giving them an explicit chunk key, or an explicit client key, or getting the client from the repository. I failed to come up with a sensible abstraction for this for how. I'll leave that module to have a lot of repetitive code, for now. Spent time failing to refactor. There's too much coupling here.

The reason for all that flexibility to the user is that in troubleshooting situations it can be crucial to be flexible. Thus, I can't simplify the code by removing functionality.
Change all other places where client_key_from_repo is used, and then dropped that function. This went a bit beyond the goal, but that's OK.
After my meandering, I never did add a method to the client context to unlock a client. Getting the client key is enough, for now.
It's possible I should split the obnam crate further, and have a crate just for the library part. That might make it easier to build abstractions for the command line client that only make sense for that. I'll have to think about this.

Summary

The work to introduce a client context is done. The command line tool is in need of refactoring, but that can wait. I can build restore functionality next, I think.

Support?

If you'd like to fund Obnam development, see my funding page. My high level goal is described on the architecture page. What is most important about backup software to you?