Tracking: Loosen Key Package Upload Validation

[neekolas]

The goal of this project is to allow clients to upload key packages before publishing identity updates. While we are rolling out these changes, we can do a bit of cleanup of some of the legacy APIs that predate the identity work.

Because of some frontend->backend dependencies, we'll need to roll this out in at least two phases.

Phase 1

- [x] Change logic in `RegisterInstallation` and `UploadKeyPackage` to not validate that the key package is part of a given inbox. Instead it should just validate the signatures and extract the installation ID.
- [x] Update database schema to not store the `inbox_id` on installations, since we don't have that trusted information after the first change. Also remove the expiration field
- [x] Update client to call `UploadKeyPackage` _before_ publishing an identity update adding the installation
- [x] Remove `RegisterInstallation` and `GetIdentityUpdates` APIs from the libxmtp traits
- [x] Make the `ValidateInboxIdKeyPackages` endpoint in the validation service stop checking the lifetime of key packages, since that check will panic if the lifetime is not set
- [x] Stop setting a lifetime on new key packages. This will prevent them from expiring

Phase 2

- [ ] Roll out changes from phase 1 to all clients
- [ ] In the `PublishIdentityUpdate` flow, check to make sure the installation is already registered. Reject any identity updates that reference an installation that does not have a key package stored in the DB.
- [ ] Remove `RegisterInstallation`, `RevokeInstallation` and `GetIdentityUpdates` from the protos and server
- [ ] Remove `ValidateInboxIds` and `ValidateKeyPackages` endpoints from the MLS validation service and protos