(cherry picked from commit 85ae1d2)

RFC 2045 states that any invalid character should be skipped over, this
is the RFC used by mime handler in Suricata code to deal with base64
encoded data.
So far, only spaces were skipped as a part of implementation of this
RFC, extend it to also skip over any other invalid character. Add
corresponding test.

(cherry picked from commit e46b033)

Padding bytes for the last remainder data should be as follows:

Case   |    Remainder bytes     |    Padding
----------------------------------------------
  I    |              1         |      3
  II   |              2         |      2
  III  |              3         |      1

However, we calculate the decoded_bytes with the formula:
decoded_bytes = ASCII_BLOCK - padding

this means for Case I when padding is 3 bytes, the decoded_bytes would
be 0. This is incorrect for any trailing data. In any of the above
cases, if the parsing was successful, there should at least be 1 decoded
byte.

(cherry picked from commit 095c335)

Just like the check for destination buffer size done previously for
complete data, it should also be done for the trailing data to avoid
goind out of bounds.

(cherry picked from commit 0e8b451)

The destination buffer should be able to hold at least 3 Bytes during
the processing of the last block of data. If it cannot hold at least 3
Bytes, then that may lead to dynamic buffer overflow while decoding.

(cherry picked from commit 62d7821)

(cherry picked from commit c2ae87e)

(cherry picked from commit 49ad383)

For certain edge case handling for spaces, spaces were handled
particularly in the remainder processing functions. Make sure that now
that as per RFC 2045, util-base64 would skip over any invalid char, the
edge cases in MIME processor also be handled the same way.

This completes the work done in e46b033.

Ticket 6135
Ticket 6207

(cherry picked from commit 789353b)