fix: Uptake public key hash changes

[sitaram-kalluri]

- What I did

• Consume the publicKeyHash changes.
  • In the abstract_update_verb_handler.dart, from the verb params, populate the publicKeyHash value to the atKey.metadata.publicKeyHash field
  • In the sync_proressive_verb_handler.dart, jsonEncode the publicKeyHash value from the metadataMap to sync to the client. On the client side, to build the PublicKeyHash instance (which contains hash and hashing algo), jsonEncod the publicKeyHash and on the client side jsonDecode the string to build publicKeyHash instance.
  • In the notify_verb_handler.dart and resource_manager.dart, the set the publicKeyHash value to send the publicKeyHash value to the notification receiver.
  • In the monitor_verb_handler.dart, add publicKeyHash value for the clients which receives notifications via the monitor.

- How to verify it

• Updated the existing sync_verb_test.dart to ensure the publicKeyHash value is added to the metadata when data is synced to the client.

- Description for the changelog

• fix: Uptake public key hash changes

[gkc]

• Please add functional tests for update-then-lookup, update-then-sync for the same atSign
• Please add end-to-end tests to verify the end-to-end flows also

[sitaram-kalluri]

• Please add functional tests for update-then-lookup, update-then-sync for the same atSign

• Please add end-to-end tests to verify the end-to-end flows also

@gkc : I have added a functional test for the update-then-sync scenario for the specified atSign, which verifies that the atKey.metadata contains the publicKeyHash in the sync response.

we have a known issue with reaching the other atSign in the functional tests, which prevents us from including the update-then-lookup scenario in those tests. So, included this in the end-to-end tests.

The end-to-end staging test is currently failing because the changes are not available in the trunk branch.

[gkc]

@sitaram-kalluri As discussed earlier, let's first do a at_secondary_server PR which does nothing except take up next version of at_persistence_secondary_server so it gets the new typeAdapter; once that has been rolled out to prod then we have a stable place to roll back to if we need to. Have marked this PR as draft so we don't accidentally merge yet.

[sitaram-kalluri]

@gkc : All the tests are passing expect the test in "end2end_test_staging".

Although we have a version check in the test, it fails in the "end2end_test_staging" because the staging server returns the secondary server version as v3.1.0. The secondary version with 3.1.0 is still in the trunk and hasn't been released to canary. To ensure the "end2end_test_staging" test passes, shall we release version 3.1.0 to canary and update the feature branch version to 3.1.1?

[gkc]

@gkc : All the tests are passing expect the test in "end2end_test_staging".

Although we have a version check in the test, it fails in the "end2end_test_staging" because the staging server returns the secondary server version as v3.1.0. The secondary version with 3.1.0 is still in the trunk and hasn't been released to canary. To ensure the "end2end_test_staging" test passes, shall we release version 3.1.0 to canary and update the feature branch version to 3.1.1?

sounds good to me