Handle non-ascii community values in incoming traps without crashing

[lunkwill42]

A device that sends traps with non-Ascii community values would cause trap PDU processing to crash with a UnicodeDecodeError.

Community values are defined as ASCII in the SNMP specs, but some devices do not behave. netsnmp-cffi tries to be helpful to the client by automatically making a Python string from the community, but if there's a misbehaving device, this shouldn't break everything. This PR falls back to storing the raw bytes objects in the trap data structure if it cannot be successfully decoded as ASCII.

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ PYTHON	black	2		0	0	0.69s
✅ PYTHON	isort	2		0	0	0.28s
✅ PYTHON	ruff	2		0	0	0.16s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

[github-actions]

Test results

  4 files    4 suites   40s ⏱️
 25 tests  25 ✅ 0 💤 0 ❌
100 runs  100 ✅ 0 💤 0 ❌

Results for commit 7bc9d71.

♻️ This comment has been updated with latest results.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.62%. Comparing base (4120d26) to head (7bc9d71).

Additional details and impacted files

@@            Coverage Diff             @@
##           master       #9      +/-   ##
==========================================
+ Coverage   72.05%   77.62%   +5.56%     
==========================================
  Files          10       10              
  Lines        1256     1260       +4     
==========================================
+ Hits          905      978      +73     
+ Misses        351      282      -69     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[he32]

Community values are defined as ASCII in the SNMP specs

Really? RFC 1902 (yes, obsoleted), has

        Message ::=
                SEQUENCE {
                     version
                        INTEGER {
                            version(1)  -- modified from RFC 1157
                        },

                    community           -- community name
                        OCTET STRING,

                    data                -- PDUs as defined in [4]
                        ANY
                }
        }

[...] but some devices do not behave.

I would perhaps not have said it that way. Instead, I would have said that "it is a bad assumption to insist that everyone configuring SNMP community strings input only utf-8 valid sequences in the community string".

Other than that, I think this change does the right thing and no longer insist on conformance to utf-8 coding, and instead just looks at this as an octet string.