[receiver/azureeventhub] remove continue from timestamp parse failure

[nslaughter]

Description:

Link to tracking Issue:

• Timestamp parse failure drops log record Timestamp parse failure drops log record #31244

Testing:
Analyzed log records with and without this change.

Documentation:

[mwear]

LGTM

[cparkins]

@nslaughter - If this is standard practice elsewhere, I think it makes sense. I intentionally skipped these records because they are really hard to find in Splunk. Maybe it makes sense to add a warning? I'll look at other receivers and see what they do. What do you think @atoulme?

[nslaughter]

per comments of @cparkins

Changed behavior so we set Timestamp if we receive a parseable time from Azure and we always set ObservedTimestamp per description of the field in the data model.

Added the option to IgnoreObservedTimestamp in test as we now set the observed timestamp to code observed time, per field description in logs data model; however that breaks test expectation that ALL fields match test record.

And noted I need to stop force pushing, so I don't disappear the comments.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[nslaughter]

hi @dashpole, I have an approving review from a codeowner. However, this may not show it as he wasn't a codeowner when the PR began? ... So I'm pinging. Hoping you can help getting this merged as assignee. Thank you!

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[cparkins]

I'd like to see these changes get integrated. Can we get this reopened? I believe we have users that are experiencing this issue and it would be good to get more information. I believe these changes are good in general anyway.

@atoulme - Can you open this back up?