Wrap the raw pointers exposed across the bridge as named types that approximate
Swift's OpaquePointer?. Parameterize NativeHandleOwner with the native handle
type.
At this point, the only special behavior of bridge_fn_buffer is to
support multiple return values for the C bridge (a pointer/length
pair), and that doesn't pull its weight. Remove it in favor of a plain
bridge_fn.
This did reveal that Username_Hash was using bridge_fn_buffer and now
produces a fixed-size array, imported into Swift as a tuple, so this
commit also factors out a new helper invokeFnReturningFixedLengthArray.
Like ProfileKeyCredential, but with an expiration timestamp embedded
in it. This has its own credential type and response type, but uses
the same request type as a "classic" ProfileKeyCredential, and
generates presentations usable with AnyProfileKeyCredential-
Presentation, so that existing server code accepting presentations
will automatically do the right thing.
Adoption for servers:
- Update secret params
- When presentations are saved in group state, use
ProfileKeyCredentialPresentation.getStructurallyValidV1PresentationBytes()
to maintain backwards compatibility with existing clients.
- Add an endpoint to issue ExpiringProfileKeyCredentials
- (future) Remove the endpoint that issues regular ProfileKeyCredentials
Adoption for clients, after the server has updated:
- Update public params
- Start fetching and using ExpiringProfileKeyCredentials instead of
regular ProfileKeyCredentials (the old endpoint will eventually
go away)
- Node: To bring types into harmony, a receipt's expiration time has
been changed to a `number` instead of a `bigint`
Optimize presentation of credentials (AuthCredentialPresentationV2, ProfileKeyCredentialPresentationV2, PniCredentialPresentationV2). Server will accept V1 or V2 presentations. Clients will produce V2.
Various improvements to FFI to support this, and some minor optimizations (in particular "lazy statics" to avoid redundant loading of SystemParams).
