FMD: initial `Clue` parameter selection

[redshiftzero]

Write some code to, based on current network conditions - i.e. rate of transactions per epoch - provide a reasonable choice of Clue parameters, i.e. as a user if we want a given FPR we should set clue parameters to X

See related comment here: https://github.com/penumbra-zone/penumbra/pull/1312#discussion_r954544436:

But if transactions with the wrong FMD precision are rejected, the requirement that the precision be defined pre-signing is effectively placing a bound on how long a signer can take to authorize a transaction, so we should consider that timing when deciding how frequently to adjust the precision.

Sub items:

• [x] Provide functionality in the node side to update the FMD parameters
• [ ] Implement functionality to add a sliding window measurement of network activity, where network activity is in terms of number of outputs. It should take a number of blocks (maybe an epoch's worth to start?)
• [x] Describe the attacks we consider
• [ ] Come up with some reasonable initial choice that scales the precision based on network activity

[redshiftzero]

relevant discussion in https://github.com/penumbra-zone/penumbra/issues/4

[hdevalence]

I think this would make sense to do together with work on gas pricing in #2972, since they're pretty similar problems.

[hdevalence]

To start, let's target 1,000 detections per 24 hour window.

[redshiftzero]

Based on synchronous discussion 02/15/2024, the plan here is to:

• Set the initial false positive rate at mainnet launch to that which corresponds to a target detection rate of 512 or 1000 tx/day. This is the anonymity set provided by the system. If users don't like the choice here, then they can choose not to opt-in to using S-FMD.
• Add logic that changes the false positive rate as a function of network activity based on the target rate parameter (i.e. if network activity changes, the fpr should change such that the target detection rate is held constant). This could be something fairly simple, i.e. we count transactions in each epoch, updated in EndBlock. Then we can later use this data by a PID controller which sets the FMD precision.
• This target rate should be updateable via governance. This will enable changes to the FMD parameters without performing a network upgrade. Further changes to this algorithm would require a network upgrade.

[cronokirby]

Work on this was delayed by having other higher priority items bumped in front of it.