Consolidate Twined repository

[cortadocodes]

Epic

We want a clear proposition for what the different octue products are - at the moment "octue" the company has a range of services and applications, whilst "octue" the python package is about services and functions (ie actually implements what we call twined).

We wish to rework this so that octue (the SDK package) can span the whole range of Octue's offerings, and so that the twined ecosystem has a clear offering, purpose and place to exist.

Decision

We had considered splitting out to create several separate packages, but for the sake of bulletproof version management (and because our set of services isn't so large that a single repository becomes cumbersome).
Based on discussions here, we've decided to:

• keep code in a single repository
• in a way that subpackages could be split out later (then their CLIs reimported into the octue CLI) should we grow to need a more maintainable solution
• in a way that is logically separated and presentationally separated so we can show clear product offerings within the one package, beginning with twined.

Migration plan

• Move twined repo code into a twined subpackage of octue-sdk
• Archive twined repository
• Move twined-related elements of octue-sdk down into twined subpackage
• Move current CLI commands down into octue twined subcommand
• Redraft documentation so that either there’s a clear ‘twined’ top level heading (eg octue.readthedocs.org/twined) or there is a separate documentation set for each subpackage (eg twined.readthedocs.org, strands.readthedocs.org)
  • If the former, make sure twined.readthedocs.org has a redirection notice to the new docs
  • Documentation should be comprehensively redrafted to be much more approachable for newcomers
  • Use the section dividers in https://sphinx-themes.org/sample-sites/sphinx-rtd-theme/ to help
• Rename octue deploy create-push-subscription subcommand to octue twined create-push-subscription, factor the logic out into a function within a deploy subpackage, and consider whether a CLI command is needed at all (if it isn’t, change the github action to use the function)
• Versioning carries on as normal, as we only deal with the octue-sdk repo for twined

This means:

• Users carry on installing octue-sdk as normal
• New sub-SDKs and clients can be added to octue-sdk as they’re developed as either a subpackage or as separate repositories that are imported
• In the future, we can move the twined subpackage back into its own repository if needed
  • Corollary: we sit on the twined pypi package rather than releasing it
• CLI has a breaking change but it’s not like changing the whole thing to twined run, twined start, etc.