Use map for attribute lookup in MultiAttribute::check_associated

[mliszcz]

To slightly improve remove_attribute performance when multiple writable attributes are configured (fixes #556).

[t-b]

Looks good.

Two minor comments:

• If we can rely on get_attr_ind_by_name doing the transform->lower we can ditch it here.
• I'm a big fan of reducing indentation and returning early. So I would write it as

if (write_type != Tango::READ_WITH_WRITE && write_type != Tango::READ_WRITE)
  {
    return;
  }

but that is just taste I guess.

[mliszcz]

Thanks @t-b. I've changed the PR as you suggested. @bourtemb could you please check as well?

[bourtemb]

Thanks @mliszcz
Just a comment on the origin field in the exceptions thrown, but this was like that before this PR.
I think we could change that.
Except that, this PR looks good to me!

[t-b]

@mliszcz Will you do a backports PR?

[mliszcz]

@t-b sure, I can backport if you want. I don't know what is the policy for backports - do we backport everything that can be backported or just critical bugfixes? Can I assume that I should backport everything that is tagged with "Candidate for backport" maybe?

[t-b]

@mliszcz Well I thought you added the "Candidate for backport" tag, but that was me. From my understanding "Candidate for backport" means that this should get backported. But maybe we need a different name then. @bourtemb Thoughts?

[bourtemb]

From my understanding "Candidate for backport" means that this should get backported.

I think we can take this convention indeed but we might need to discuss before to put this tag on a PR to decide whether it is worth being backported.

In the case of this PR, I would say if it is easy to backport, we can do it but it does not look like a critical bug fix to me, so I would personally not put a high priority on this one.

[mliszcz]

I'll send a backport PR. It was waiting for a review for more than a year without conflicts. I think I just need to cherry-pick relevant commits and do not expect any conflicts in 9.3-backports.