leading_coefficient() may unexpectedly be zero

[moCello]

Summary

Polynomials are stored as a vector of BlsScalars. A polynomial is the zero polynomial if 1) it is empty or 2) all coefficients in the vector are zero. We don’t want to store extra zero coefficients if we don’t need to, so almost every function on polynomials makes sure to call self.truncate_leading_zeros() after each operation.

However, there are two exceptions: in add_assign and in sub_assign, if two polynomials have the same degree, then truncate_leading_zeros() is not called. It’s possible for the highest coefficients to cancel out, leaving us with a non-zero polynomial that still has a “zero” leading coefficient.

In 'fft/polynomial.rs', the leading_coefficient() function should return the largest non-zero coefficient of the polynomial. Currently, this function is marked as dead_code and not used anywhere in the repository, but future developers of this library could easily make a mistake here.
Recommendation: Either fix leading_coefficient() to ignore leading zeros, or change add_assign and sub_assign to call truncate_leading_zeros in the case of two polynomials with the same degree.

Relevant Context (optional)

Finding 1 of the plonk audit.

[moCello]

I would even go for both fixes:

• Change add_assign and sub_assign to truncate leading zeros before returning
• And also fix leading_coefficient to not return an unexpected zero coefficient

[moCello]

Additionally I propose to also truncate the leading zeros before returning a Polynomial::from_slice in 'fft/polynomial.rs' line 47.