bgv: parameter selection computations during lowerings for BGV

[asraa]

For BGV, a user may specify a number of bits for a prime modulus. We should likely integrate a library that can generate prime moduli given the number of bits needed.

Likewise, we need analysis passes that can compute optimal # of moduli bits per level and integrate that into secret-to-bgv.

[github-actions]

This issue has 1 outstanding TODOs:

• lib/Conversion/SecretToBGV/SecretToBGV.cpp:40: Integrate a general library to compute appropriate prime moduli

This comment was autogenerated by todo-backlinks

[AlexanderViand-Intel]

In addition to the plaintext/ciphertext moduli, there's a bunch of other parameters that are less user-visible but still necessary for bgv->poly. Here's a (likely still incomplete) list of parameters and parameter-derived constants that we need to select/compute (or take as input):

Ring & Security Parameters

• $N$ - ring dimension / degree of the polynomial modulus $X^N+1$
• $p$ - plaintext modulus - plaintext space is $\mathbb{Z}_p/(X^N+1)$
• $Q$ - ciphertext modulus
• Ciphertext Modulus Chain: Individual $q_i$ with $Q = \prod q_i$ for $i \in [0, l]$.
  Depending on the variant/ noise management approach, we can parameterize this in different ways
  (one bit width for all, individual bit widths, one relative scale relation, individual scale relations, etc).
  This also determines the number of RNS limbs to be $l$.
• $\lambda$ - security parameter
• $\sigma$ - standard deviation of the error distribution (frequently hardcoded to 3.2, see Section 2.5.1 here)

Key-Switching Parameters

$P$ - "special" prime (key-switching happens mod $PQ$)
$\omega$ - number of digits in the digit decomposition

Parameter-Derived Metadata

• NTT twiddle factors (powers of roots of unity) EDIT: I think those we can leave for the poly->target lowerings
• Fast Basis Conversion/Modswitch constants (things such as $p^{-1}Q'/Q \mod Q$)

[AlexanderViand-Intel]

Linking this to #543, which is similar, but about NTT twiddle factors and is leaning towards generating them externally and hardcoding them into the HEIR source code, rather than adding some math library to the dependencies.