Metal integration

[coreyeng]

Eventually I'm going to learn how to do more easily digestible PRs… but this ain't the one. Although there's half a billion changes, most are under the umbrella of "moving this thing from origen to origen_metal". With that though, came quite a bit of refactoring and some re-architecting to fully separate the setup and utility-to-utility interactions from assumptions the application would meet. Then, there were more changes needed to get the application to boot properly while allowing sufficient freedom in the setup.

Although there's still global setup required, my mantra is "the utility is there, and its up to the origen_metal user/owner to setup appropriately". For example, in origen_metal, origen_metal.current_user wil not just work - there's some setup required. I believe this is what we want though - full separation and complete control over the utilities being used. The OM user can setup whichever and however they want. All the flexibility desired will hopefully be provided.

origen then takes on the role of pre-configuring origen metal, into a more end-user friendly, albeit rigid, setup. For example, origen.current_user, which calls origen_metal.current_user underneath, will just work (or at least make the necessary complaints) as the setup has already occurred during application boot-up.

That is pretty much what this PR is. Although there are new features and some spec updates, most were made necessary due to this restructuring of both the code and the new origen/origen_metal relationship.

I'm still not sure if we decided to axe Sphinx completely. I'm 50/50 on it myself. Well, I'm actually ~80% in favor of switching to something else but the sunk cost fallacy is making me say 50/50. It may yet be salvable. I say this attempting to justify, mostly to myself, in opening this PR without docs (and nullifying most of the existing stuff). That said, I have tests out the wazoo. There's still some items left, and I've marked as such with TEST_NEEDED, (I use TODO Tree so I can filter and incrementally work on them) but this should give a good baseline for consistent behavior going forward and provide the use cases/examples for everything.

Some other notes:

• I have quite a few supported features (or ideas for things) that were cut from the Origen->OM refactoring. I'll be going through those, but I have the items either TODO-ed, TEST_NEEDED-ed, or xfail-ed/skipped in the unit tests. I plan to go through those as time allows but waiting for those will likely drag this on even longer and make it even less digestible than it already is.
• I think a lot of the CLI that doesn't go through the frontend was already suspect, and its likely not any better off now. However, much of the CLI is hard-coded and with the updates external to the CLI, the flexibility as a whole is greatly increased. I don't have a use case for things like proj (though @xnappo, maybe we can find one) but I should be able to build some dummy tests using just git to make sure it goes through the motions. At least for me, that is a lower priority though, but it is on the list.
• @ginty, @pderouen , I bumped the Poetry and Pip versions which fixed the CLI warnings. I reverted back to the old test.
• I updated the PyO3 version to 16.5. This generated a ton of deprecation warnings, which are all fixed, but much better updating now as warnings were significantly easier to deal with than the 200+ errors that would've resulted instead. But, this will pile on a lot more diffs too.
• The free LDAP server I am using seems to be pickier now about its requests. Not sure if its because I'm using a lot more of them now or what, but the regressions are prone to failing because the LDAP will reject multiple, simultaneous requests from the same IP- and I think each job running in parallel from the same general IP is exacerbating this. I will be looking into this and I'm hoping to find some sort of shared mechanism where we can still run the LDAP tests in all jobs without issue, but, at least currently, these tests are flakey. If you see a failure and wait about an hour to rerun failed jobs, they usually pass. @ginty, I know this is a pain, and worse case, we can just disable the tests or only run them for a single version for Linux/Windows, but since its really just you and I working on this at the moment, I'd like to keep them around and I'll continue to see how I can make them better.

[ginty]

@redxeth, note that this may break the origen proj command which I think you said may be used within your team.

There's no regression test for that currently, so just be aware of this and if you need/want to upgrade your O2 installation you might need to check if this still works for you (if not we would fix it once we know what's wrong with it).

[redxeth]

Thanks @ginty -- not sure if/when we'll upgrade the O2 for that since no one, at least in NVM, is yet using it. Many are not forward looking as much and I'm not sure

If we did I would say that yes we could contribute to adding a regression test to it. Until then I'll have to remember or find this comment sometime in the future when things break...

@redxeth, note that this may break the origen proj command which I think you said may be used within your team.

There's no regression test for that currently, so just be aware of this and if you need/want to upgrade your O2 installation you might need to check if this still works for you (if not we would fix it once we know what's wrong with it).