refactor(octane): separate Octane into its own repo

[ttarsi]

once audits complete and octane stablizes, let's move it to its own repo so it's more intuitive for other teams to import and use

[corverroos]

This isn't trivial, since:

• /halo depends on /octane

• /octane depends on some libraries in /lib

  So if we split out /octane, we also need to split out these libraries from the omni mono repo.

  "github.com/omni-network/omni/lib/errors"
  "github.com/omni-network/omni/lib/ethclient"
  "github.com/omni-network/omni/lib/expbackoff"
  "github.com/omni-network/omni/lib/k1util"
  "github.com/omni-network/omni/lib/log"
  "github.com/omni-network/omni/lib/tutil"

  Or maybe try the following work arounds:

• errors: we could look at refactor octane to use std go errors, which means we loose all our nice structured error stuff 😢
• ethclient: we should be able to use the standard geth interface. Testing might be tricky since that depends on the omni mock geth client. Maybe we can duplicate this?
• expbackoff: we could just duplicate this in octane.
• k1util: we could just duplicate this code in octane.
• log: we can expose an logger interface and require it in the keeper constructor.
• tutil: we could just duplicate this code in octane.

[arajasek]

@ttarsi Can you chime in on how urgently you'd like this? It's not a huge win for mainnet launch, but we can prioritize it for ancillary goals.

[ttarsi]

not super high priority - can be post mainnet, especially given it's non-trivial

[ttarsi]

I'm going to close this. We'll want someone to become DRI on Octane, and be empowered to make decisions like this