Since this is just a migration code path, I'm okay with it.

Looks fine to me, let bartek have a look

rust looks fine. Not a big fan of parsing text for certain values though.

but I'm not clear on how all of them connect to the JS.

Use SORT_KEY

Rebase on master and feedback in other diffs

Rebase on previous changes

Rebase on master

Address feedback

Apply feedback, rebase on master

Rebase on master

Rebase on master

Rebase on master

Rebase on master

Rebase on master

Rebase on master

Rebase on master

Rebase on master

Rebase on master

Minor fixups, rebase on master

Add SORT_KEY alias

Apply feedback

Address feedback

Just noticed that VerifyUserAccessTokenRequest requires userID – does that need to be included in TBSharedConnectionInitializationMessage too?

Remove JS commits in git history to avoid CI failures

Address feedback

fixup

Rename SessionRequest to ConnectionInitializationMessage

Update aws_config

removed deviceOS and deviceAppVersion. As I think those were "legacy" concepts from the previous tunnelbroker paradigms. Those details should exist in the identity server, and should be available once we authenticate sessions.

Address feedback

Address feedback

I think a better solution long term would be to have a struct which reflects the values specific to the config in question:

#[derive(Serialize, Deserialize)]
pub struct KeyserverConfig {
  password: String,
  database: String,
  dbType: String,
  host: String
  user: String
}