Consolidate all bridged engine wrappers into a single wrapper and macro.

[mhammond]

Seeing #7439 fly past reminded me that I was intending to try and remove the BridgedEngine entirely - this doesn't quite achieve that, but does get closer.

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

[jo]

Thanks a lot, that's really cool!

What would we need to do to get rid of the $guid type parameter? Do you have any idea why we don't use a sync_guid::Guid for logins as well? Is it because we need to expose it, and UniFFI does not support a sequence<Guid> thing yet?

[bendk]

The changes look good to me. I still don't totally understand the bridged engine code, but AFAICT this macro code is exactly the same as before and it makes it easier to add a new bridged engine.

[mhammond]

Do you have any idea why we don't use a sync_guid::Guid for logins as well? Is it because we need to expose it, and UniFFI does not support a sequence thing yet?

IIRC, it predates the guid type. I think uniffi would handle it fine - like places, it would be a "custom type". OTOH though, I'm a little ambivalent about that type, in that it doesn't really add much value - there's no validation that it is shaped like a guid and we have Into/From to move between strings and guids. It is kinda nice as a kind of documentation though, but could also be viewed as extra complexity without much value.

(I can't argue with the fact that we are inconsistent with its usage is quite smelly though, so maybe moving logins to guid would make sense - it would be entirely transparent to foreign code as there it really is just a string)