Generation's Deserialize impl should guard against too-large values

[jgallagher]

Generation currently has a derived Deserialize impl:

omicron/common/src/api/external/mod.rs

Lines 728 to 745 in 6fb91c6

	/// Generation numbers stored in the database, used for optimistic concurrency
	/// control
	// Because generation numbers are stored in the database, we represent them as
	// i64.
	#[derive(
	Copy,
	Clone,
	Debug,
	Deserialize,
	Eq,
	Hash,
	JsonSchema,
	Ord,
	PartialEq,
	PartialOrd,
	Serialize,
	)]
	pub struct Generation(u64);

However, it has a note that the values should fit in an i64, and we validate that in next():

omicron/common/src/api/external/mod.rs

Line 769 in 6fb91c6

assert!(next_gen <= i64::MAX as u64);

There is no equivalent validation performed when deserializing, so I believe we could get an API request with a Generation in the range (i64::MAX, u64::MAX] and bypass the checks. I strongly suspect this doesn't really matter in practice today; Generation only appears in internal APIs, and we have no way for well-behaved clients to construct a Generation in that range to send. But it's still technically wrong and could lead to weird issues if we somehow did have a client pass a bad value, hence this issue.

[sunshowers]

Aha yes, I was thinking of this while falling asleep last night haha :) will fix.