parsing requestId from message and stamping it as attribute

[hrai-nr]

This PR is for supporting the existing requestId feature from our previous implementation where we were parsing each message and if the message has "RequestId: UUID", we are parsing it and adding it as an attribute.

In our earlier implementation this attribute was named aws.lambda_request_id, but in this implementation we will be using the attribute name as requestId. This is done to make it similar to the key name which aws is sending when the log type is of json.

This change is only applicable to log message which are of type normal text message. For Json type message we are not changing anything.

Testing Done:

1. Positive case: Send a valid message "START RequestId: d653fb2c-0234-46ff-ae6b-9a418b888420 Version: $LATEST INFO ERROR hrai", the message will flow to new relic and an attribute named requestId with value d653fb2c-0234-46ff-ae6b-9a418b888420 is attached to the logs in new relic.

2. Positive case: Send a valid message with 2 UUID "START RequestId: d653fb2c-0234-46ff-ae6b-9a418b888420 Version: $LATEST START RequestId: d653fb2c-0234-46ff-ae6b-9a418b888422 Version: $LATEST hrai INFO ERROR", the message will flow to new relic and an attribute named requestId with value d653fb2c-0234-46ff-ae6b-9a418b888420 (first occurence of UUID)is attached to the logs in new relic. (This is just a test case and we won't get two UUID in same message.)

3. Send a json:
   {
   "time": "2024-12-12T11:40:11Z",
   "level": "INFO",
   "message": "hrai hello",
   "logger": "root",
   "requestId": "6bff3185-1cee-4c13-addb-0c038a197abc"
   }
   here also the attribute named requestId with value 6bff3185-1cee-4c13-addb-0c038a197abc will be attached to the logs. ( This was working earlier as well, no changes, just testing regression)

4. Send a complex JSON:
   {
   "time": "2024-12-12T11:40:11.054Z",
   "type": "platform.report ERROR",
   "record": {
   "requestId": "6bff3185-1cee-4c13-addb-0c038a197abc",
   "metrics": {
   "durationMs": 9.335,
   "billedDurationMs": 10,
   "memorySizeMB": 128,
   "maxMemoryUsedMB": 30,
   "initDurationMs": 92.552
   },
   "status": "success",
   "level": "INFO"
   }
   }

Here also the attribute named record.requestId with value 6bff3185-1cee-4c13-addb-0c038a197abc will be attached to the logs. ( This was working earlier as well, no changes, just testing regression)

5. Negative test case: Send messge: "START RequestId:d653fb-0234-46ff-ae6b-9a418b888420 Version: $LATEST INFO ERROR hrai", since it won't match our regex we won't attach any attribute to the logs.

6. Negative test case: Send messge: "START RequestId: d653fb-0234-46ff-ae6b-9a418b888420 Version: $LATEST INFO ERROR hrai", since it won't match our regex we won't attach any attribute to the logs. (The UUID is not valid UUID)

[sanathramesh]

nit : I don't think this if check needs to be a part of the for loop since every message is going to have the same log group

[sanathramesh]

@hrai-nr
I don't think pr actually implements the feature similar to previous lambda implementation.
This is how the previous lambda worked :
Log Line 1 : START RequestId: d653fb2c-0234-46ff-ae6b-9a418b888420 Version: $LATEST INFO ERROR hrai
Log Line 2 : some random log
If this was processed by previous lambda it would append the requestId to both the log lines.
The current implementation would not append the request Id to subsequent requests.

[sanathramesh]

I would suggest you to move the parsing logic to message_util. it would help in reusability and unit testing.

Also please write unit tests