Stop removing periods from the end of output names

[tlangs]

Description

CollectMultipleMetrics currently strips a trailing period from the OUTPUT parameter. This behavior is unexpected and causes problems in our cloud pipelines. Metrics files, by convention, are names ${sample_alias}.${metrics_suffix}. In removing a trailing . from the OUTPUT, CollectMultipleMetrics writes unexpected file names, causing problems when our cloud pipelines try to delocalize files. When supplied an OUTPUT of foo.bar., the resulting metrics files should look like foo.bar..pre_adapter_detail_metrics. This is still a valid path in all filesystems.

---

Checklist (never delete this)

Never delete this, it is our record that procedure was followed. If you find that for whatever reason one of the checklist points doesn't apply to your PR, you can leave it unchecked but please add an explanation below.

Content

• Added or modified tests to cover changes and any new functionality
• Edited the README / documentation (if applicable)
• All tests passing on Travis

Review

• Final thumbs-up from reviewer
• Rebase, squash and reword as applicable

For more detailed guidelines, see https://github.com/broadinstitute/picard/wiki/Guidelines-for-pull-requests

[gbggrant]

Looks good. I think this is the correct behavior. @yfarjoun might want to take a look to see if there are any edge cases you are not aware of.

[yfarjoun]

I think that this requires more as this could be a breaking change for many users....since the user of CollectMultipleMetrics has no idea that the program will add the suffix with a . as opposed to without. I agree that a consistent behavior is better, especially for consistent pipelines that might have a period at the end of a sample-name (why-oh-why?!!?)

Perhaps each "Program" could include in its description the list of suffixes that it will use? This can be done by having Program implement ClpEnum.

[yfarjoun]

I actually did the ClpEnum thing now in #1555 so @tlangs do you want to re-evaluate the importance of this PR?

[kbergin]

@tlangs I recall us going through some iterations of this being implemented/causing prod issues/getting fixed last year. I'm going through open picard prs now, is this PR still relevant?

[jessicaway]

@tlangs Are we good to close this PR?