feat: Add ability to track messages based on known VAPID keys

[jrconlin]

Note: This introduces a new setting for autoendpoint: tracking_keys
This is a JSON formatted list of the "raw"/x962 formatted VAPID public keys that should be monitored for Push tracking and follows the same format as other key data fields.

The newly added script/convert_pem_to_x962.py script aids by reading a VAPID public key PEM file and outputing a x962 formatted string.

Closes: SYNC-4349

[jrconlin]

This was changed from a simple bool to an Option<String> since that's most likely the final form of this. For now, we're just using a "filler" UUID4, but I strongly suspect that https://mozilla-hub.atlassian.net/browse/SYNC-3400 will introduce a more formalized tracking_id generator.

[pjenvey]

Seems like the comment still reflects the bool -- so it needs an update

[jrconlin]

Well, it is an option, so it has bool like properties (None vs. Some). I'll clarify the comment.

[pjenvey]

doesn't seem like a necessary TODO?

Suggested change

//TODO: convert to decoded Vec<u8>?

[jrconlin]

It kinda is.
Ideally, the key we track should be the bytearray of the decoded public key. This would prevent things like case confusion or formatting errors. Since we are using a consistently formatted, well known key, we can short cut things for now and just do string matches, but that's very much a cheat.

[pjenvey]

Ok, but I think we can still kill this tracking_vapid_pubs field entirely since we're only calling tracking_keys() once at startup now. Then the comment should probably move to that method

[pjenvey]

Since this isn't an actual setting I think it should live in AppState instead. Then fn tracking_keys won't need to do caching.

(the existing fn auth_keys should probably similarly live in AppState too instead of it reparsing the setting every time but I don't think it's that heavily called).

It'll make it more annoying to test -- but can we just wrap it in a quick tuple struct with an is_trackable method to avoid needing an AppState for the test?

struct VapidTracker(Vec<String);
impl VapidTracker {
    pub fn is_trackable(...
}

[pjenvey]

Seems like the comment still reflects the bool -- so it needs an update

R's applied

[pjenvey]

Ok, but I think we can still kill this tracking_vapid_pubs field entirely since we're only calling tracking_keys() once at startup now. Then the comment should probably move to that method

[pjenvey]

These chains can be a bit much but I'd argue utilzing and_then/ok improves this since we'll only need new_v4 at the very end (also surprised clippy didn't force unwrap_or_else here).

Suggested change

	.map(|s| {
	s.to_str()
	.unwrap_or(uuid::Uuid::new_v4().as_simple().to_string().as_str())
	.to_string()
	})
	.unwrap_or(uuid::Uuid::new_v4().as_simple().to_string())
	.and_then(|val| val.to_str().ok())
	.map(|s| s.to_owned())
	.unwrap_or_else(|| uuid::Uuid::new_v4().as_simple().to_string())