Remove unnecessary logging

[belimawr]

What does this PR do?

The log line remove by this commit is unnecessary, it is not an actual
error in the sense something will not work. It only means the
harvester is already running for this file so another one does not
need to be started. Keeping this log line will only spam our log files
and make users worried.

Why is it important?

It was spamming our logs and would make our uses worry for no good reason

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
  - [ ] I have made corresponding changes to the documentation
  - [ ] I have made corresponding change to the default configuration files
  - [ ] I have added tests that prove my fix is effective or that my feature works
  - [ ] I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

## Author's Checklist

How to test this PR locally

Run Filebeat with the filestream input enabled, you should not see log errors like:

• error while adding new reader to the bookkeeper harvester is already running for file
• harvester:: error while adding new reader to the bookkeeper harvester is already running for file

## Related issues
## Use cases
## Screenshots
## Logs

[elasticmachine]

Pinging @elastic/elastic-agent (Team:Elastic-Agent)

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @belimawr? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-05-11T18:17:54.513+0000

• Duration: 71 min 0 sec

Test stats 🧪

Test	Results
Failed	0
Passed	7809
Skipped	749
Total	8558

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[rdner]

I agree that it's not an error but we still should log it at least at the debug level.

[belimawr]

This path can be triggered by events watched by the file watcher, which can be a lot, even o debug level I believe it's too verbose.

I let it running on my machine for a while, in 2h there were about 2000 of those messages for a single active file (the Agent's log file). They're duplicated because the task.Group also logs it, so about 500 messages per hour per file if it's logged on debug mode. I still believe it's too much.

What do you think?

[belimawr]

Being honest, I believe the best fix would for the newContext method to just be a no-op on this case. However I did not want to change any implementation details as we already created the 8.8 branch.

beats/filebeat/input/filestream/internal/input-logfile/harvester.go

Lines 69 to 81 in ba662b8

	func (r *readerGroup) newContext(id string, cancelation inputv2.Canceler) (context.Context, context.CancelFunc, error) {
	r.mu.Lock()
	defer r.mu.Unlock()
	if _, ok := r.table[id]; ok {
	return nil, nil, ErrHarvesterAlreadyRunning
	}
	ctx, cancel := context.WithCancel(ctxtool.FromCanceller(cancelation))
	r.table[id] = cancel
	return ctx, cancel, nil
	}

[rdner]

I think it's okay in the current form.