Fixed md5 buffer in LLMD5::finalize not being correctly zero-initialized

[Hecklezz]

Fixes the error mentioned in my issue posted here-
#2500

Unless I am mistaken and it is intentional, the md5 buffer in the LLMD5::finalize function is being incorrectly zeroized and instead only the first byte is being zeroized.

Also went ahead and refactored the code so it more closely matches the styling of the rest of the codebase.

[marchcat]

Nice! Thank you!

[marchcat]

Mac build fails with

/Users/runner/work/viewer/viewer/indra/llcommon/llmd5.cpp:219:10: error: array type 'uint8_t[64]' is not assignable
  buffer = {};
  ~~~~~~ ^
1 error generated.

so the buffer should be either initialized as

std::array<uint8_t, 64> buffer = {};

or, alternatively, we can use std::fill:

std::fill(std::begin(buffer), std::end(buffer), 0);

[Hecklezz]

Whoops my bad, I really should have tested compiling first before blindly making that change and trusting intellisense that it said nothing was wrong and not remembering that C arrays are not assignable like that after they have already been defined.

Should we stick with memset since a large portion of the rest of the codebase is still using memset, or should the code be changed to be more in line with modern C++ standards?

[Nicky-D]

While at it, can we maybe change the finalized member to a bool?

Regarding memset. If this is down deemed security related and the buffer must be cleared, then memset_s or something like SecureZeroMemory needs to be employed.
Otherwise the compiler can happily optimize that call to memset away (dunno if it would do here, probably not?)

[Hecklezz]

I went back to using regular memset. Doing some googling, supposedly MSVC does not even have memset_s implemented even if you set the define it wants, and SecureZeroMemory is windows specific so that isn't helpful either.

I also went ahead and did a bit of a tidy-up of the llmd5 files so they weren't so outdated interms of code styling.

[marchcat]

It looks much better now.

Thank you for your efforts!