Rename `lightning/src/chain/keysinterface.rs` to something like `signer.rs`

[ariard]

The file was originally named after the KeysInterface trait which doesn't exist anymore after #1930. This is a bit of confusion for downstream project and our documentation (which sounds to require a cleanup too: https://lightningdevkit.org/key_management/)

[gantanikhilraj]

Hello @ariard, I can work on this. Please assign it to me.

[arik-so]

Hey @ariard, @gantanikhilraj, and @TomNag-CS50, part of an upcoming Taproot PR is actually renaming it to sign, and elevating it to a directory module. We're also moving it outside of chain, and instead make it a sibling directory. Would you like to do that yourselves, or are you fine with waiting for the Taproot PR?

[0xSaksham]

Hey, this seems like a good issue for me to start. Please point me to further resources if need be

[TheBlueMatt]

Sounds like something that should happen as a prefactor PR either way, no?

[arik-so]

Partially. With the upgrade to a directory module for the purpose of having a separate file for Taproot-specific signing operations, it might not make sense outside the context of the Taproot PR, but I'm not that opinionated.

[jkczyz]

Hey @ariard, @gantanikhilraj, and @TomNag-CS50, part of an upcoming Taproot PR is actually renaming it to sign, and elevating it to a directory module. We're also moving it outside of chain, and instead make it a sibling directory. Would you like to do that yourselves, or are you fine with waiting for the Taproot PR?

FWIW, I had some proposed naming and further sub-module breakdown in a parallel effort. #2159 (comment)

Thoughts?

[arik-so]

I think the overarching subject is actually signing, so I'd stick with the sign top-level module name. It makes more sense to put entropy into sign than into key imo. 100% agree on manager. The signer I think should just live in mod.rs. I'd also create submodules for taproot and later maybe ecdsa or legacy or whatnot.