feat(base): Add EncryptionState::StateEncrypted

[kaylendog]

• Add EncryptionState::StateEncrypted to represent the encryption state of rooms supporting state event encryption.

[codspeed-hq]

CodSpeed Performance Report

Merging #5523 will not alter performance

_{Comparing kaylendog:kaylendog/msc3414/encyption-state (18b5679) with main (4f0415d)}

Summary

✅ 31 untouched benchmarks

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.59%. Comparing base (4f0415d) to head (18b5679).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5523   +/-   ##
=======================================
  Coverage   88.59%   88.59%           
=======================================
  Files         340      340           
  Lines       93836    93836           
  Branches    93836    93836           
=======================================
+ Hits        83133    83135    +2     
+ Misses       6572     6571    -1     
+ Partials     4131     4130    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Hywan]

Thanks for the patch!

I believe these is a design issue with the new StateEncrypted variant. See my comment.

[kaylendog]

Looks like this breaks the Go FFI bindings in complement-crypto

[Hywan]

Looks like this breaks the Go FFI bindings in complement-crypto

Yes, you may need to update Complement Crypto. Ideally, you can open a branch on Complement Crypto with the same name as your branch here, to trigger a special build that will help tests both PR at the same time.

[kaylendog]

Reverted back to the enum variant after the discussion with @richvdh.

[Hywan]

I continue to believe the changes I've recommended before are the way to go, but @richvdh brought a pretty relevant argument in favor of the current solution I'm about the approve. My solution is a breaking change, the new solution isn't a breaking change. Knowing this is an experimental feature, avoiding a breaking change is definitely better. We can still refactor later once it's stablised.