Auth Next changes in SDK

[dmkozh]

What

Adapt Soroban SDK to the host changes introduced in stellar/rs-soroban-env#645

Overview of the changes:

• Replace the AccountId, invoker, and soroban-auth library with the single Address type that supports host-based authentication and authorization.
• Use the recording auth for testing and provide a simple utility to verify that authorization has happened. Signatures are no longer required for tests thanks to that.
• Replace network passphrase with id (this just reflects the host-side change; we don't really need to have both available to contrats)
• Introduced a stub for the account contract SDK

Why

Auth Next motivation is described in the env PR. From the SDK perspective the auth and testing are greatly simplified.

Known limitations

Some of the possible followups:

• The account SDK would need to be developed more to provide a better support for building the custom account contracts
• Strkey should be used for displaying the addresses
• Add testing utility to verify non-top-level authorizations
• Add some macros to generate the auth code for simple cases (even though this is just a line of code, it would be more readable to have an explicit function annotation that requires a given address to authorize a call with all the input arguments).
• Maybe bring back some of the classic account related functionality for the integration testing. While this should be unnecessary for the unit tests, there may be some need for it in snapshot-based testing. Not quite certain about that yet though.

[leighmcculloch]

This is looking really nice. I have a few asks inline.

[leighmcculloch]

I think my suggestions were misunderstood in a couple places.

I think the main things left are:

1. Figuring out if we can keep network passphrase, or if we need to move to network id in the SDK. I agree network id should be used within the env.

2. Can we replace the verify_top_auth function.

It would be good to figure out (1) before merging so that we don't flip-flop the network passphrase code. But it's also fine to flip flop it if we can't figure it out.

I think we can fix (2) post-merge, but I think it is important we fix that before release, so maybe worth doing in this PR too.

[dmkozh]

I think we can fix (2) post-merge, but I think it is important we fix that before release, so maybe worth doing in this PR too.

I would suggest merging this as is (given everything else looks ok) in order to unblock your changes or any other unrelated changes. I'll prioritize this to make sure it makes it into release.

[leighmcculloch]

Looks good, +1 to following up with the remaining things.

Two things with cfgs stand out to me which I commented on inline, just because they look inconsistent with other code following the same pattern. I'll try changing them and if they work changed I'll merge. Otherwise I'll merge them as it is.

[leighmcculloch]

@dmkozh I pushed a commit before merging. See 1ae8ac0.