feat: Drop aesgcm128 support

[jrconlin]

Description

Drops support for legacy aesgcm128 encryption format. This is in parallel with mozilla/rust-ece#53 which will drop support for the format for mobile devices.

We're also seeing zero messages containing this form, so it's absolutely safe to drop it.

Testing

messages encoded with aesgcm128 should be rejected.

Issue

Closes: #266

[pjenvey]

We're also seeing zero messages containing this form, so it's absolutely safe to drop it.

It's not quite zero but it's very low now, not even 1-2 requests per second

[pjenvey]

aesgcm128 appears to be the sole user of the Encryption-Key header. We could also further remove it, killing the encryption_key field in here and related enckey entry in the router message data.

The only reference to it we might need going forward is the explicit invalidation if it was included in the request. This error's only triggered for the 04 encoding but I don't see why it couldn't apply to 06 too. If so, the check could occur in from_request instead so the struct field wouldn't be needed.

Maybe we don't even need the check any longer either?

I'm happy to defer this till later but I think it's worth the effort even for such a minor cleanup -- otherwise this field's likely to linger around forever. The various bits of the different crypto standards are complicated enough as is.